ટેસ્ટિંગ (Testing) ​

પરીક્ષણ શા માટે કરવું જોઈએ? (Why Test?) ​

ઓટોમેટેડ ટેસ્ટ તમને અને તમારી ટીમને એપ્લિકેશનને ટેસ્ટ કરી શકાય તેવા ફંક્શન્સ, મોડ્યુલ્સ, ક્લાસીસ અને કમ્પોનન્ટ્સમાં વિભાજીત કરવા પ્રોત્સાહિત કરે છે. પ્રોડક્શન રિલિઝ કરતા પહેલા તે એપ્લિકેશનમાં બગ્સ કે રેગ્રેશન્સ (regressions) શોધવામાં અને તેને જાળવવામાં તમારી મદદ કરે છે. કોઈપણ એપ્લિકેશનની જેમ, તમારી નવી Vue એપ્લિકેશન ઘણી રીતે તૂટી શકે છે, અને તે મહત્વપૂર્ણ છે કે તમે આ સમસ્યાઓને પકડી શકો અને તેને રિલિઝ કરતા પહેલા ઠીક કરી શકો.

આ માર્ગદર્શિકામાં, આપણે મૂળભૂત પરિભાષાઓને આવરી લઈશું અને તમારી Vue 3 એપ્લિકેશન માટે કયા સાધનો પસંદ કરવા તે અંગેની અમારી ભલામણો આપીશું.

કમ્પોઝેબલ્સ (composables) ને આવરી લેતો એક Vue-વિશિષ્ટ વિભાગ પણ છે. વધુ વિગતો માટે નીચે કમ્પોઝેબલ્સનું પરીક્ષણ (Testing Composables) જુઓ.

ક્યારે પરીક્ષણ કરવું (When to Test) ​

જલદી પરીક્ષણ શરૂ કરો! અમે ભલામણ કરીએ છીએ કે તમે બને તેટલી વહેલી તકે પરીક્ષણો લખવાનું શરૂ કરો. તમે તમારી એપ્લિકેશનમાં પરીક્ષણો ઉમેરવા માટે જેટલી લાંબી રાહ જોશો, તમારી એપ્લિકેશનમાં એટલી બધી ડિપેન્ડન્સીસ હશે અને તેને શરૂ કરવાનું તેટલું મુશ્કેલ હશે.

ટેસ્ટિંગના પ્રકારો (Testing Types) ​

તમારી Vue એપ્લિકેશનની પરીક્ષણ વ્યૂહરચના ડિઝાઇન કરતી વખતે, તમારે નીચેના પરીક્ષણ પ્રકારોનો લાભ લેવો જોઈએ:

• યુનિટ (Unit): તપાસે છે કે આપેલ કાર્ય (function), ક્લાસ, અથવા કમ્પોઝેબલ (composable) અપેક્ષિત આઉટપુટ અથવા સાઇડ ઇફેક્ટ્સ પેદા કરી રહ્યા છે.
• કમ્પોનન્ટ (Component): તપાસે છે કે તમારો ઘટક માઉન્ટ થાય છે, રેન્ડર થાય છે, તેની સાથે ક્રિયાપ્રતિક્રિયા કરી શકાય છે અને અપેક્ષા મુજબ વર્તે છે. આ પરીક્ષણો યુનિટ ટેસ્ટ કરતાં વધુ કોડ ધરાવે છે, વધુ જટિલ છે અને અમલમાં લાવવા માટે વધુ સમયની જરૂર છે.
• End-to-end (E2E): તમારી પ્રોડક્શન-બિલ્ટ Vue એપ્લિકેશન સામે વાસ્તવિક નેટવર્ક વિનંતીઓ (network requests) કરે છે અને બહુવિધ પેજીસમાં ફેલાયેલી સુવિધાઓ તપાસે છે. આ પરીક્ષણોમાં ઘણીવાર ડેટાબેઝ અથવા અન્ય બેકએન્ડ ઉભા કરવાનો સમાવેશ થાય છે.

દરેક પરીક્ષણ પ્રકાર તમારી એપ્લિકેશનની પરીક્ષણ વ્યૂહરચનામાં ભૂમિકા ભજવે છે અને દરેક તમને વિવિધ પ્રકારની સમસ્યાઓ સામે રક્ષણ આપશે.

વિહંગાવલોકન (Overview) ​

અમે આમાંના દરેક શું છે, Vue એપ્લિકેશન્સ માટે તેનો અમલ કેવી રીતે કરી શકાય તે વિશે ટૂંકમાં ચર્ચા કરીશું અને કેટલીક સામાન્ય ભલામણો પ્રદાન કરીશું.

યુનિટ ટેસ્ટિંગ (Unit Testing) ​

કોડના નાના, અલગ એકમો અપેક્ષા મુજબ કામ કરી રહ્યા છે તે ચકાસવા માટે યુનિટ ટેસ્ટ લખવામાં આવે છે. યુનિટ ટેસ્ટ સામાન્ય રીતે સિંગલ ફંક્શન, ક્લાસ, કમ્પોઝેબલ અથવા મોડ્યુલને આવરી લે છે. યુનિટ ટેસ્ટ લોજિકલ ચોકસાઈ પર ધ્યાન કેન્દ્રિત કરે છે અને એપ્લિકેશનની એકંદર કાર્યક્ષમતાના માત્ર નાના ભાગ સાથે જ સંબંધ ધરાવે છે. તેઓ તમારી એપ્લિકેશનના વાતાવરણના મોટા ભાગોને મોક (mock) કરી શકે છે (દા.ત. પ્રારંભિક સ્થિતિ, જટિલ ક્લાસિસ, થર્ડ પાર્ટી મોડ્યુલ્સ અને નેટવર્ક વિનંતીઓ).

સામાન્ય રીતે, યુનિટ ટેસ્ટ ફંક્શનના બિઝનેસ લોજિક અને લોજિકલ ચોકસાઈ સાથેની સમસ્યાઓને પકડી પાડશે.

ઉદાહરણ તરીકે આ increment ફંક્શન લો:

export function increment(current, max = 10) {
  if (current < max) {
    return current + 1
  }
  return current
}

કારણ કે તે ખૂબ જ સ્વનિર્ભર છે, તેથી ઇન્ક્રીમેન્ટ ફંક્શનને બોલાવવું અને તે જે પરત કરવાનું છે તે આપે છે મહાર પર તે ભાર મૂકવો સરળ રહેશે, તેથી અમે યુનિટ ટેસ્ટ લખીશું.

જો આમાંના કોઈપણ નિવેદનો (assertions) નિષ્ફળ જાય, તો તે સ્પષ્ટ છે કે સમસ્યા increment ફંક્શનની અંદર જ છે.

import { increment } from './helpers'

describe('increment', () => {
  test('increments the current number by 1', () => {
    expect(increment(0, 10)).toBe(1)
  })

  test('does not increment the current number over the max', () => {
    expect(increment(10, 10)).toBe(10)
  })

  test('has a default max of 10', () => {
    expect(increment(10)).toBe(10)
  })
})

અગાઉ સૂચવ્યા મુજબ, યુનિટ ટેસ્ટિંગ સામાન્ય રીતે સ્વનિર્ભર બિઝનેસ લોજિક, કમ્પોનન્ટસ, ક્લાસીસ, મોડ્યુલ્સ અથવા ફંક્શન પર લાગુ કરવામાં આવે છે જેમાં UI રેન્ડરિંગ, નેટવર્ક વિનંતીઓ અથવા અન્ય વાતાવરણીય ચિંતાઓનો સમાવેશ થતો નથી.

આ સામાન્ય રીતે Vue સાથે અસંબંધિત સાદા JavaScript / TypeScript મોડ્યુલ્સ છે. સામાન્ય રીતે, Vue એપ્લિકેશન્સમાં બિઝનેસ લોજિક માટે યુનિટ ટેસ્ટ લખવાનું અન્ય ફ્રેમવર્કનો ઉપયોગ કરતી એપ્લિકેશન્સથી નોંધપાત્ર રીતે અલગ નથી.

બે કિસ્સાઓ છે જ્યાં તમે Vue-વિશિષ્ટ સુવિધાઓનું યુનિટ ટેસ્ટ કરો છો:

૧. કમ્પોઝેબલ્સ (Composables) ૨. કમ્પોનન્ટ્સ (Components)

કમ્પોઝેબલ્સ (Composables) ​

Vue એપ્લિકેશન્સ માટે વિશિષ્ટ કાર્યોની એક શ્રેણી કમ્પોઝેબલ્સ છે, જેને પરીક્ષણો દરમિયાન વિશેષ હેન્ડલિંગની જરૂર પડી શકે છે. વધુ વિગતો માટે નીચે કમ્પોઝેબલ્સનું પરીક્ષણ (Testing Composables) જુઓ.

યુનિટ ટેસ્ટિંગ કમ્પોનન્ટ્સ ​

ઘટકનું પરીક્ષણ બે રીતે કરી શકાય છે:

૧. વ્હાઇટબોક્સ (Whitebox): યુનિટ ટેસ્ટિંગ

જે પરીક્ષણો "Whitebox tests" છે તેઓ ઘટકની અમલીકરણ વિગતો અને નિર્ભરતાથી વાકેફ છે. તેઓ પરીક્ષણ હેઠળના ઘટકને અલગ (isolating) કરવા પર ધ્યાન કેન્દ્રિત કરે છે. આ પરીક્ષણોમાં સામાન્ય રીતે તમારા ઘટકના કેટલાક, જો બધા નહીં તો, બાળકોની મજાક (mocking) ઉડાવવાની તેમજ પ્લગિન સ્ટેટ અને ડિપેન્ડન્સીસ (દા.ત. Pinia) સેટ કરવાની જરૂર પડશે.

૨. બ્લેકબોક્સ (Blackbox): કમ્પોનન્ટ ટેસ્ટિંગ

જે પરીક્ષણો "Blackbox tests" છે તેઓ ઘટકની અમલીકરણ વિગતોથી અજાણ હોય છે. આ પરીક્ષણો તમારા ઘટક અને સમગ્ર સિસ્ટમના એકીકરણ (integration) ને ચકાસવા માટે બને તેટલી ઓછી મજાક ઉડાવે છે. તેઓ સામાન્ય રીતે તમામ બાળ ઘટકોને રેન્ડર કરે છે અને તેને "integration test" માનવામાં આવે છે. નીચે કમ્પોનન્ટ ટેસ્ટિંગની ભલામણો જુઓ.

ભલામણ (Recommendation) ​

• Vitest

  ક્યારથી create-vue દ્વારા બનાવવામાં આવેલ સત્તાવાર સેટઅપ Vite પર આધારિત છે, અમે યુનિટ ટેસ્ટિંગ ફ્રેમવર્કનો ઉપયોગ કરવાની ભલામણ કરીએ છીએ જે તે જ કન્ફિગરેશનનો ઉપયોગ કરી શકે છે અને સીધા Vite માંથી પાઇપલાઇન ટ્રાન્સફોર્મ કરી શકે છે. Vitest એ ખાસ કરીને આ હેતુ માટે રચાયેલ યુનિટ ટેસ્ટિંગ ફ્રેમવર્ક છે, જે Vue / Vite ટીમના સભ્યો દ્વારા બનાવવામાં અને જાળવવામાં આવે છે. તે ન્યૂનતમ પ્રયત્નો સાથે Vite-આધારિત પ્રોજેક્ટ્સ સાથે સંકલિત થાય છે અને તે ખૂબ જ ઝડપી છે.

અન્ય વિકલ્પો ​

• Jest એ લોકપ્રિય યુનિટ ટેસ્ટિંગ ફ્રેમવર્ક છે. જો કે, અમે ફક્ત ત્યારે જ જેસ્ટ (Jest) ની ભલામણ કરીએ છીએ જો તમારી પાસે અસ્તિત્વમાં છે તે જેસ્ટ ટેસ્ટ સ્યુટ છે જેને વિટ (Vite) આધારિત પ્રોજેક્ટમાં માઇગ્રેટ કરવાની જરૂર છે, કારણ કે Vitest વધુ સીમલેસ ઇન્ટિગ્રેશન અને વધુ સારું પ્રદર્શન આપે છે.

કમ્પોનન્ટ ટેસ્ટિંગ (Component Testing) ​

Vue એપ્લિકેશન્સમાં, કમ્પોનન્ટ્સ UI ના મુખ્ય બિલ્ડિંગ બ્લોક્સ છે. જ્યારે તમારી એપ્લિકેશનના વર્તનને વેલિડેટ કરવાની વાત આવે ત્યારે કમ્પોનન્ટ્સ વ્યાજબી રીતે અલગતાના એકમ છે. ગ્રાન્યુલારિટી (granularity) ના પરિપ્રેક્ષ્યમાં, કમ્પોનન્ટ ટેસ્ટિંગ યુનિટ ટેસ્ટિંગથી ક્યાંક ઉપર છે અને તેને ઇન્ટિગ્રેશન ટેસ્ટિંગ (integration testing) નું સ્વરૂપ ગણી શકાય. તમારી Vue એપ્લિકેશનનો મોટાભાગનો ભાગ કમ્પોનન્ટ ટેસ્ટ દ્વારા આવરી લેવો જોઈએ અને અમે ભલામણ કરીએ છીએ કે દરેક Vue ઘટક તેની પોતાની સ્પેક ફાઇલ (spec file) ધરાવે છે.

કમ્પોનન્ટ ટેસ્ટોએ તમારા ઘટકના પ્રોપ્સ, ઇવેન્ટ્સ, તે પૂરા પાડે છે તે સ્લોટ્સ, સ્ટાઇલ્સ, ક્લાસીસ, લાઇફસાયકલ હૂક્સ અને વધુ સંબંધિત સમસ્યાઓ પકડી પાડવી જોઈએ.

કમ્પોનન્ટ ટેસ્ટ્સે ચાઇલ્ડ કમ્પોનન્ટ્સની મજાક ઉડાવવી જોઈએ નહીં, પરંતુ તેના બદલે વપરાશકર્તા જે રીતે ઘટકો સાથે ક્રિયાપ્રતિક્રિયા કરે તે રીતે તમારા ઘટક અને તેના બાળકો વચ્ચેની ક્રિયાપ્રતિક્રિયાઓ ચકાસવી જોઈએ. ઉદાહરણ તરીકે, કમ્પોનન્ટ ટેસ્ટ પ્રોગ્રામેટિકલી ઘટક સાથે ક્રિયાપ્રતિક્રિયા કરવાને બદલે વપરાશકર્તા જે રીતે એલિમેન્ટ પર ક્લિક કરે તે રીતે ક્લિક કરવી જોઈએ.

કમ્પોનન્ટ ટેસ્ટ્સે આંતરિક અમલીકરણ વિગતોને બદલે ઘટકના સાર્વજનિક ઇન્ટરફેસ પર ધ્યાન કેન્દ્રિત કરવું જોઈએ. મોટાભાગના ઘટકો માટે, સાર્વજનિક ઇન્ટરફેસ આ સુધી મર્યાદિત છે: ઉત્સર્જિત ઇવેન્ટ્સ, પ્રોપ્સ અને સ્લોટ્સ. પરીક્ષણ કરતી વખતે, યાદ રાખો કે ઘટક શું કરે છે તેનું પરીક્ષણ કરો, તે કેવી રીતે કરે છે તેનું નહીં.

આ કરો (DO)

• વિઝ્યુઅલ (Visual) લોજિક માટે: ઇનપુટ કરેલા પ્રોપ્સ અને સ્લોટ્સના આધારે સાચું રેન્ડર આઉટપુટ છે કે નહીં તે ભારપૂર્વક કહો.

• વર્તણૂકીય (Behavioral) લોજિક માટે: વપરાશકર્તા ઇનપુટ ઇવેન્ટ્સના જવાબમાં સાચા રેન્ડર અપડેટ્સ અથવા ઉત્સર્જિત ઇવેન્ટ્સ છે કે નહીં તે તપાસો.

  નીચેના ઉદાહરણમાં, અમે એક સ્ટેપર (Stepper) ઘટક પ્રદર્શિત કરીએ છીએ જેમાં "increment" લેબલ ધરાવતું DOM એલિમેન્ટ છે અને તેને ક્લિક કરી શકાય છે. અમે max નામનો પ્રોપ પાસ કરીએ છીએ જે સ્ટેપરને 2 થી આગળ વધતા અટકાવે છે, તેથી જો આપણે બટનને ૩ વખત ક્લિક કરીએ, તો UI એ હજી પણ 2 કહેવું જોઈએ.

  અમને Stepper ના અમલીકરણ વિશે કંઈ જ ખબર નથી, ફક્ત એટલું જ કે "ઇનપુટ" એ max પ્રોપ છે અને "આઉટપુટ" એ DOM ની સ્થિતિ છે કારણ કે વપરાશકર્તા તેને જોશે.

const valueSelector = '[data-testid=stepper-value]'
const buttonSelector = '[data-testid=increment]'

const wrapper = mount(Stepper, {
  props: {
    max: 1
  }
})

expect(wrapper.find(valueSelector).text()).toContain('0')

await wrapper.find(buttonSelector).trigger('click')

expect(wrapper.find(valueSelector).text()).toContain('1')

const valueSelector = '[data-testid=stepper-value]'
const buttonSelector = '[data-testid=increment]'

mount(Stepper, {
  props: {
    max: 1
  }
})

cy.get(valueSelector)
  .should('be.visible')
  .and('contain.text', '0')
  .get(buttonSelector)
  .click()
  .get(valueSelector)
  .should('contain.text', '1')

const { getByText } = render(Stepper, {
  props: {
    max: 1
  }
})

getByText('0') // "0" ઘટકની અંદર છે તે ગર્ભિત પ્રતિપાદન (Implicit assertion)

const button = getByRole('button', { name: /increment/i })

// અમારા ઇન્ક્રીમેન્ટ બટન પર ક્લિક ઇવેન્ટ ડિસ્પેચ કરો.
await fireEvent.click(button)

getByText('1')

await fireEvent.click(button)

આ ન કરો (DON'T)

• ઘટક ઇન્સ્ટન્સની પ્રાઇવેટ સ્ટેટ પર ભાર મૂકશો નહીં અથવા ઘટકની પ્રાઇવેટ મેથડ્સનું પરીક્ષણ કરશો નહીં. અમલીકરણ વિગતોનું પરીક્ષણ પરીક્ષણોને બરડ બનાવે છે, કારણ કે જ્યારે અમલીકરણ બદલાય છે ત્યારે તેઓ તૂટી જવાની અને અપડેટ્સની જરૂર પડવાની શક્યતા વધુ હોય છે.

  ઘટકનું અંતિમ કાર્ય સાચું DOM આઉટપુટ રેન્ડર કરવાનું છે, તેથી DOM આઉટપુટ પર ધ્યાન કેન્દ્રિત કરતા પરીક્ષણો સમાન સ્તરની ચોકસાઈ ખાતરી આપે છે (જો વધુ નહીં તો) જ્યારે કે તે વધુ મજબૂત અને પરિવર્તન સામે લચીલા હોય છે.

  વિશિષ્ટ રીતે સ્નેપશોટ (snapshot) પરીક્ષણો પર આધાર રાખશો નહીં. HTML સ્ટ્રિંગ્સ પ્રતિપાદિત કરવું ચોકસાઈનું વર્ણન કરતું નથી. ઈરાદાપૂર્વક પરીક્ષણો લખો.

  જો કોઈ પદ્ધતિનું સંપૂર્ણ પરીક્ષણ કરવાની જરૂર હોય, તો તેને સ્ટેન્ડઅલોન ઉપયોગિતા કાર્ય (utility function) માં એક્સટ્રેક્ટ કરવાનું અને તેના માટે સમર્પિત યુનિટ ટેસ્ટ લખવાનું વિચારો. જો તેને સ્પષ્ટ રીતે એક્સટ્રેક્ટ કરી શકાતું નથી, તો તેને ઘટક, એકીકરણ અથવા એન્ડ-ટુ-એન્ડ ટેસ્ટના ભાગ રૂપે પરીક્ષણ કરી શકાય છે જે તેને આવરી લે છે.

ભલામણ (Recommendation) ​

• કમ્પોનન્ટ્સ અથવા કમ્પોઝેબલ્સ માટે Vitest જે હેડલેસલી (headlessly) રેન્ડર થાય છે (દા.ત. VueUse માં useFavicon ફંક્શન). કમ્પોનન્ટ્સ અને DOM ને @vue/test-utils નો ઉપયોગ કરીને ટેસ્ટ કરી શકાય છે.

• જે કમ્પોનન્ટ્સની અપેક્ષિત વર્તણૂક પ્રોપરલી રેન્ડરિંગ સ્ટાઈલ અથવા નેટિવ DOM ઇવેન્ટ્સ ટ્રિગર કરવા પર આધાર રાખે છે તેના માટે Cypress Component Testing. તેનો ઉપયોગ ટેસ્ટિંગ લાઇબ્રેરી સાથે @testing-library/cypress દ્વારા કરી શકાય છે.

Vitest અને બ્રાઉઝર-આધારિત રનર્સ વચ્ચેના મુખ્ય તફાવતો ઝડપ અને અમલીકરણ સંદર્ભ (execution context) છે. ટૂંકમાં, બ્રાઉઝર-આધારિત રનર્સ, જેમ કે સાયપ્રસ (Cypress), એવી સમસ્યાઓને પકડી શકે છે જે નોડ-આધારિત રનર્સ, જેમ કે Vitest, કરી શકતા નથી (દા.ત. સ્ટાઇલ સમસ્યાઓ, વાસ્તવિક નેટિવ DOM ઇવેન્ટ્સ, કૂકીઝ, લોકલ સ્ટોરેજ અને નેટવર્ક નિષ્ફળતાઓ), પરંતુ બ્રાઉઝર-આધારિત રનર્સ Vitest કરતા કલાકો ધીમા હોય છે કારણ કે તેઓ બ્રાઉઝર ખોલે છે, તમારી સ્ટાઇલશીટ્સ કમ્પાઇલ કરે છે અને ઘણું બધું કરે છે. સાયપ્રસ એ બ્રાઉઝર-આધારિત રનર છે જે ઘટક પરીક્ષણને સપોર્ટ કરે છે. Vitest અને Cypress ની સરખામણી કરતી નવીનતમ માહિતી માટે કૃપા કરીને Vitest નું સરખામણી પેજ વાંચો.

માઉન્ટિંગ લાઇબ્રેરીઝ (Mounting Libraries) ​

કમ્પોનન્ટ ટેસ્ટિંગમાં ઘણીવાર પરીક્ષણ કરવામાં આવતા ઘટકને આઇસોલેશનમાં માઉન્ટ કરવાનો, સિમ્યુલેટેડ વપરાશકર્તા ઇનપુટ ઇવેન્ટ્સને ટ્રિગર કરવાનો અને રેન્ડર કરેલા DOM આઉટપુટ પર ભાર મૂકવાનો સમાવેશ થાય છે. ત્યાં સમર્પિત યુટિલિટી લાઇબ્રેરીઝ છે જે આ કાર્યોને સરળ બનાવે છે.

• @vue/test-utils એ સત્તાવાર લો-લેવલ કમ્પોનન્ટ ટેસ્ટિંગ લાઇબ્રેરી છે જે વપરાશકર્તાઓને Vue વિશિષ્ટ APIs ની એક્સેસ આપવા માટે લખવામાં આવી હતી. તે લો-લેવલ લાઇબ્રેરી પણ છે જેના પર @testing-library/vue બનાવવામાં આવ્યું છે.

• @testing-library/vue એ Vue પરીક્ષણ લાઇબ્રેરી છે જે અમલીકરણ વિગતો પર આધાર રાખ્યા વિના ઘટકોના પરીક્ષણ પર ધ્યાન કેન્દ્રિત કરે છે. તેનો માર્ગદર્શક સિદ્ધાંત એ છે કે સોફ્ટવેર જે રીતે ઉપયોગમાં લેવાય છે તેની સાથે પરીક્ષણો જેટલા વધુ મળતા આવે છે, તેટલો વધુ આત્મવિશ્વાસ તેઓ પ્રદાન કરી શકે છે.

અમે એપ્લિકેશન્સમાં ઘટકોના પરીક્ષણ માટે @vue/test-utils નો ઉપયોગ કરવાની ભલામણ કરીએ છીએ. @testing-library/vue ને સસ્પેન્સ (Suspense) સાથે એસિંક ઘટકના પરીક્ષણમાં સમસ્યાઓ છે, તેથી તેનો સાવધાની સાથે ઉપયોગ કરવો જોઈએ.

અન્ય વિકલ્પો ​

• Nightwatch એ Vue કમ્પોનન્ટ ટેસ્ટિંગ સપોર્ટ સાથેનું E2E ટેસ્ટ રનર છે. (ઉદાહરણ પ્રોજેક્ટ)

• પ્રમાણભૂત ઓટોમેશન પર આધારિત નેટિવ વપરાશકર્તા ક્રિયાપ્રતિક્રિયા પર આધાર રાખતા ક્રોસ-બ્રાઉઝર ઘટક પરીક્ષણ માટે WebdriverIO. તેનો ઉપયોગ ટેસ્ટિંગ લાઇબ્રેરી સાથે પણ થઈ શકે છે.

E2E ટેસ્ટિંગ (E2E Testing) ​

જ્યારે યુનિટ ટેસ્ટ ડેવલપર્સને અમુક અંશે આત્મવિશ્વાસ પૂરો પાડે છે, ત્યારે યુનિટ અને કમ્પોનન્ટ ટેસ્ટ પ્રોડક્શનમાં ડિપ્લોય કરવામાં આવે ત્યારે એપ્લિકેશનનું સર્વગ્રાહી કવરેજ પૂરું પાડવાની તેમની ક્ષમતાઓમાં મર્યાદિત હોય છે. પરિણામે, end-to-end (E2E) પરીક્ષણો એપ્લિકેશનના સૌથી મહત્વપૂર્ણ પાસાં પર કવરેજ પૂરું પાડે છે: જ્યારે વપરાશકર્તાઓ ખરેખર તમારી એપ્લિકેશનોનો ઉપયોગ કરે છે ત્યારે શું થાય છે.

End-to-end પરીક્ષણો મલ્ટિ-પેજ એપ્લિકેશન વર્તણૂક પર ધ્યાન કેન્દ્રિત કરે છે જે તમારી પ્રોડક્શન-બિલ્ટ Vue એપ્લિકેશન સામે નેટવર્ક વિનંતીઓ (network requests) કરે છે. તેઓ ઘણીવાર ડેટાબેઝ અથવા અન્ય બેકઅપ ઉભા કરે છે અને કદાચ લાઇવ સ્ટેજીંગ વાતાવરણ સામે પણ ચલાવવામાં આવે છે.

End-to-end પરીક્ષણો ઘણીવાર તમારા રાઉટર, સ્ટેટ મેનેજમેન્ટ લાઇબ્રેરી, ટોપ-લેવલ કમ્પોનન્ટ્સ (દા.ત. એપ અથવા લેઆઉટ), પબ્લિક એસેટ્સ અથવા કોઈપણ વિનંતી હેન્ડલિંગ સાથેની સમસ્યાઓને પકડી પાડશે. ઉપર જણાવ્યા મુજબ, તેઓ જટિલ સમસ્યાઓ પકડે છે જે યુનિટ ટેસ્ટ અથવા કમ્પોનન્ટ ટેસ્ટ દ્વારા પકડવી અશક્ય હોઈ શકે છે.

End-to-end પરીક્ષણો તમારી Vue એપ્લિકેશનના કોઈપણ કોડને ઇમ્પોર્ટ કરતા નથી પરંતુ તેના બદલે વાસ્તવિક બ્રાઉઝરમાં સમગ્ર પેજીસ નેવિગેટ કરીને તમારી એપ્લિકેશનના પરીક્ષણ પર સંપૂર્ણપણે આધાર રાખે છે.

End-to-end પરીક્ષણો તમારી એપ્લિકેશનમાંના ઘણા સ્તરોને વેલિડેટ કરે છે. તેઓ કાં તો તમારી સ્થાનિક રીતે બિલ્ટ એપ્લિકેશન અથવા તો લાઇવ સ્ટેજીંગ (Staging) વાતાવરણને પણ લક્ષ્ય બનાવી શકે છે. તમારા સ્ટેજીંગ વાતાવરણ સામે પરીક્ષણ કરવાથી માત્ર તમારા ફ્રન્ટએન્ડ કોડ અને સ્ટેટિક સર્વર જ નહીં પરંતુ તમામ સંબંધિત બેકએન્ડ સેવાઓ અને ઇન્ફ્રાસ્ટ્રક્ચરનો સમાવેશ થાય છે.

તમારા ટેસ્ટ તમારા સોફ્ટવેરના ઉપયોગની રીત સાથે જેટલા વધુ મળતા આવે છે, તેટલો વધુ આત્મવિશ્વાસ તેઓ તમને આપી શકે છે. - Kent C. Dodds - ટેસ્ટિંગ લાઇબ્રેરીના લેખક

વપરાશકર્તાની ક્રિયાઓ તમારી એપ્લિકેશનને કેવી રીતે અસર કરે છે તેનું પરીક્ષણ કરીને, E2E પરીક્ષણો ઘણીવાર એપ્લિકેશન યોગ્ય રીતે કાર્ય કરી રહી છે કે નહીં તેના પર ઉચ્ચ આત્મવિશ્વાસ મેળવવા માટેની ચાવી છે.

E2E ટેસ્ટિંગ સોલ્યુશન પસંદ કરવું ​

જ્યારે વેબ પર એન્ડ-ટુ-એન્ડ (E2E) પરીક્ષણે અવિશ્વસનીય (flaky) પરીક્ષણો અને ડેવલપમેન્ટ પ્રક્રિયાઓને ધીમી કરવા માટે નકારાત્મક છાપ ઊભી કરી છે, ત્યારે આધુનિક E2E સાધનોએ વધુ વિશ્વસનીય, ઇન્ટરેક્ટિવ અને ઉપયોગી પરીક્ષણો બનાવવા માટે તે દિશામાં પ્રગતિ કરી છે. જ્યારે E2E પરીક્ષણ માળખું પસંદ કરતી વખતે, નીચેના વિભાગો તમારી એપ્લિકેશન માટે પરીક્ષણ ફ્રેમવર્ક પસંદ કરતી વખતે ધ્યાનમાં રાખવા જેવી બાબતો પર માર્ગદર્શન પૂરું પાડે છે.

ક્રોસ-બ્રાઉઝર ટેસ્ટિંગ (Cross-browser testing) ​

એન્ડ-ટુ-એન્ડ (E2E) પરીક્ષણ જે પ્રાથમિક ફાયદાઓ માટે જાણીતું છે તે પૈકીનું એક બહુવિધ બ્રાઉઝર્સ પર તમારી એપ્લિકેશનને ચકાસવાની તેની ક્ષમતા છે. જ્યારે ૧૦૦% ક્રોસ-બ્રાઉઝર કવરેજ હોવું ઇચ્છનીય લાગે છે, તે નોંધવું મહત્વપૂર્ણ છે કે તેમને સતત ચલાવવા માટે જરૂરી વધારાના સમય અને મશીન પાવરને કારણે ટીમની સંપત્તિ (resources) પર ક્રોસ-બ્રાઉઝર ટેસ્ટિંગના વળતરમાં ઘટાડો થાય છે. પરિણામે, તમારી એપ્લિકેશનને કેટલા ક્રોસ-બ્રાઉઝર પરીક્ષણની જરૂર છે તે પસંદ કરતી વખતે આ ટ્રેડ-ઓફ (trade-off) નું ધ્યાન રાખવું મહત્વપૂર્ણ છે.

ઝડપી પ્રતિસાદ લૂપ્સ (Faster feedback loops) ​

એન્ડ-ટુ-એન્ડ (E2E) પરીક્ષણો અને ડેવલપમેન્ટ સાથેની પ્રાથમિક સમસ્યાઓમાંની એક એ છે કે સમગ્ર સ્યુટ ચલાવવામાં લાંબો સમય લાગે છે. લાક્ષણિક રીતે, આ માત્ર સતત એકીકરણ અને જમાવટ (CI/CD) પાઇપલાઇન્સમાં કરવામાં આવે છે. આધુનિક E2E પરીક્ષણ માળખાએ પેરેલેલાઇઝેશન (parallelization) જેવી સુવિધાઓ ઉમેરીને આને ઉકેલવામાં મદદ કરી છે, જે CI/CD પાઇપલાઇન્સને ઘણીવાર પહેલા કરતા ઘણી ઝડપથી ચલાવવાની મંજૂરી આપે છે. વધુમાં, જ્યારે સ્થાનિક રીતે ડેવલપમેન્ટ કરો છો, ત્યારે તમે જે પેજ પર કામ કરી રહ્યા છો તેના માટે પસંદગીરૂપે એક જ પરીક્ષણ ચલાવવાની ક્ષમતા સાથે પરીક્ષણોને હોટ રીલોડિંગ આપવાથી ડેવલપરના કાર્યપ્રવાહ અને ઉત્પાદકતામાં વધારો કરવામાં મદદ મળી શકે છે.

ફર્સ્ટ ક્લાસ ડિબગિંગ અનુભવ ​

જ્યારે ડેવલપર્સ પરંપરાગત રીતે ટર્મિનલ વિન્ડોમાં લોગ સ્કેન કરવા પર આધાર રાખે છે તે નક્કી કરવામાં મદદ કરવા માટે કે ટેસ્ટમાં શું ખોટું થયું છે, આધુનિક એન્ડ-ટુ-એન્ડ (E2E) ટેસ્ટ ફ્રેમવર્ક ડેવલપર્સને તે સાધનોનો લાભ લેવાની મંજૂરી આપે છે જેનાથી તેઓ પહેલેથી જ પરિચિત છે, દા.ત. બ્રાઉઝર ડેવલપર ટૂલ્સ.

હેડલેસ મોડમાં વિઝિબિલિટી (Visibility in headless mode) ​

જ્યારે એન્ડ-ટુ-એન્ડ (E2E) પરીક્ષણો સતત એકીકરણ/જમાવટ પાઇપલાઇન્સમાં ચલાવવામાં આવે છે, ત્યારે તેઓ ઘણીવાર હેડલેસ (headless) બ્રાઉઝર્સમાં ચલાવવામાં આવે છે (એટલે ​​કે, વપરાશકર્તાને જોવા માટે કોઈ દૃશ્યમાન બ્રાઉઝર ખોલવામાં આવતું નથી). આધુનિક E2E પરીક્ષણ માળખાની એક મહત્વપૂર્ણ વિશેષતા એ છે કે પરીક્ષણ દરમિયાન એપ્લિકેશનના સ્નેપશોટ અને/અથવા વિડિઓઝ જોવાની ક્ષમતા, જે શા માટે ભૂલો થઈ રહી છે તેની અમુક સમજ પૂરી પાડે છે. ઐતિહાસિક રીતે, આ સંકલનને જાળવવું કંટાળાજનક હતું.

ભલામણ (Recommendation) ​

• Playwright એ એક ઉત્તમ E2E પરીક્ષણ સોલ્યુશન છે જે Chromium, WebKit અને Firefox ને સપોર્ટ કરે છે. Windows, Linux અને macOS પર, સ્થાનિક રીતે અથવા CI પર, હેડલેસ અથવા હેડેડ (headed) Android માટે Google Chrome અને Mobile Safari ના નેટિવ મોબાઇલ ઇમ્યુલેશન સાથે પરીક્ષણ કરો. તે માહિતીપ્રદ UI, ઉત્તમ ડિબગબિલિટી, બિલ્ટ-ઇન નિવેદનો (assertions), પેરેલેલાઇઝેશન, ટ્રેસ ધરાવે છે અને અસ્પષ્ટ (flaky) પરીક્ષણોને દૂર કરવા માટે રચાયેલ છે. ઘટક પરીક્ષણ (Component Testing) માટે સપોર્ટ ઉપલબ્ધ છે, પરંતુ તે પ્રાયોગિક તરીકે ચિહ્નિત થયેલ છે. પ્લેરાઈટ (Playwright) ઓપન સોર્સ છે અને માઈક્રોસોફ્ટ દ્વારા જાળવવામાં આવે છે.

• Cypress પાસે માહિતીપ્રદ ગ્રાફિકલ ઇન્ટરફેસ, ઉત્તમ ડિબગબિલિટી, બિલ્ટ-ઇન નિવેદનો, સ્ટબ્સ, ફ્લેક-રેઝિસ્ટન્સ અને સ્નેપશોટ છે. ઉપર જણાવ્યા મુજબ, તે કમ્પોનન્ટ ટેસ્ટિંગ માટે સ્થિર સપોર્ટ પૂરો પાડે છે. સાયપ્રસ (Cypress) Chromium-આધારિત બ્રાઉઝર્સ, Firefox અને Electron ને સપોર્ટ કરે છે. WebKit સપોર્ટ ઉપલબ્ધ છે, પરંતુ પ્રાયોગિક તરીકે ચિહ્નિત થયેલ છે. સાયપ્રસ MIT-લાઇસન્સ્ડ છે, પરંતુ પેરેલેલાઇઝેશન જેવી કેટલીક સુવિધાઓ માટે સાયપ્રસ ક્લાઉડના સબ્સ્ક્રિપ્શનની જરૂર છે.

ટેસ્ટિંગ સ્પોન્સર

Lambdatest એ તમામ મુખ્ય બ્રાઉઝર્સ અને વાસ્તવિક ઉપકરણો પર E2E, એક્સેસિબિલિટી અને વિઝ્યુઅલ રિગ્રેશન ટેસ્ટ ચલાવવા માટેનું ક્લાઉડ પ્લેટફોર્મ છે, જેમાં AI મદદથી ટેસ્ટ જનરેશન છે!

અન્ય વિકલ્પો ​

• Nightwatch એ Selenium WebDriver પર આધારિત E2E પરીક્ષણ ઉકેલ છે. આ તેને નેટિવ મોબાઇલ પરીક્ષણ સહિત વિશાળ બ્રાઉઝર સપોર્ટ શ્રેણી આપે છે. સેલેનિયમ-આધારિત સોલ્યુશન્સ પ્લેરાઈટ અથવા સાયપ્રસ કરતા ધીમા હશે.

• WebdriverIO એ વેબ અને મોબાઇલ પરીક્ષણ માટેનું ટેસ્ટ ઓટોમેશન ફ્રેમવર્ક છે જે WebDriver પ્રોટોકોલ પર આધારિત છે.

રેસીપીઝ (Recipes) ​

પ્રોજેક્ટમાં Vitest ઉમેરવું ​

Vite-આધારિત Vue પ્રોજેક્ટમાં, ચલાવો:

> npm install -D vitest happy-dom @testing-library/vue

આગળ, test ઓપ્શન બ્લોક ઉમેરવા માટે Vite કન્ફિગરેશન અપડેટ કરો:

import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  test: {
    // jest જેવી વૈશ્વિક ટેસ્ટ APIs સક્ષમ કરો
    globals: true,
    // happy-dom સાથે DOM નું અનુકરણ કરો
    // (પીઅર ડિપેન્ડન્સી તરીકે happy-dom ઇન્સ્ટોલ કરવાની જરૂર છે)
    environment: 'happy-dom'
  }
})

{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

પછી, તમારા પ્રોજેક્ટમાં *.test.js થી સમાપ્ત થતી ફાઇલ બનાવો. તમે પ્રોજેક્ટ રૂટમાં ટેસ્ટ ડિરેક્ટરીમાં અથવા તમારી સોર્સ ફાઇલોની બાજુમાં ટેસ્ટ ડિરેક્ટરીઓમાં બધી ટેસ્ટ ફાઇલો મૂકી શકો છો. Vitest નામકરણ પ્રણાલીનો ઉપયોગ કરીને તેમને આપમેળે શોધશે.

import { render } from '@testing-library/vue'
import MyComponent from './MyComponent.vue'

test('તે કામ કરવું જોઈએ', () => {
  const { getByText } = render(MyComponent, {
    props: {
      /* ... */
    }
  })

  // આઉટપુટ પ્રતિપાદિત કરો (assert)
  getByText('...')
})

છેલ્લે, ટેસ્ટ સ્ક્રિપ્ટ ઉમેરવા અને તેને ચલાવવા માટે package.json અપડેટ કરો:

{
  // ...
  "scripts": {
    "test": "vitest"
  }
}

> npm test

કમ્પોઝેબલ્સનું પરીક્ષણ (Testing Composables) ​

આ વિભાગ ધારે છે કે તમે કમ્પોઝેબલ્સ વિભાગ વાંચ્યો છે.

જ્યારે કમ્પોઝેબલ્સના પરીક્ષણની વાત આવે છે, ત્યારે આપણે તેમને બે શ્રેણીઓમાં વિભાજીત કરી શકીએ છીએ: કમ્પોઝેબલ્સ કે જે હોસ્ટ કમ્પોનન્ટ ઇન્સ્ટન્સ પર આધાર રાખતા નથી, અને કમ્પોઝેબલ્સ જે રાખે છે.

જ્યારે તે નીચેના APIs નો ઉપયોગ કરે છે ત્યારે કમ્પોઝેબલ હોસ્ટ કમ્પોનન્ટ ઇન્સ્ટન્સ પર આધાર રાખે છે:

• લાઇફસાયકલ હૂક્સ
• Provide / Inject

જો કમ્પોઝેબલ માત્ર રિએક્ટિવિટી APIs નો ઉપયોગ કરે છે, તો તેને સીધું જ ઇન્વોક કરીને અને તેની પરત કરેલી સ્ટેટ/મેથડ્સને ભારપૂર્વક કહીને ટેસ્ટ કરી શકાય છે:

import { ref } from 'vue'

export function useCounter() {
  const count = ref(0)
  const increment = () => count.value++

  return {
    count,
    increment
  }
}

import { useCounter } from './counter.js'

test('useCounter', () => {
  const { count, increment } = useCounter()
  expect(count.value).toBe(0)

  increment()
  expect(count.value).toBe(1)
})

એકાદ કમ્પોઝેબલ જે લાઇફસાયકલ હૂક્સ અથવા Provide / Inject પર આધાર રાખે છે તેનું પરીક્ષણ કરવા માટે તેને હોસ્ટ કમ્પોનન્ટમાં લપેટવાની (wrapped) જરૂર છે. આપણે નીચે મુજબની મદદગાર (helper) બનાવી શકીએ છીએ:

import { createApp } from 'vue'

export function withSetup(composable) {
  let result
  const app = createApp({
    setup() {
      result = composable()
      // મિસિંગ ટેમ્પલેટ ચેતવણીને દબાવો
      return () => {}
    }
  })
  app.mount(document.createElement('div'))
  // ટેસ્ટિંગ પ્રોવાઇડ/અનમાઉન્ટ માટે પરિણામ અને એપ ઇન્સ્ટન્સ પરત કરો
  return [result, app]
}

import { withSetup } from './test-utils'
import { useFoo } from './foo'

test('useFoo', () => {
  const [result, app] = withSetup(() => useFoo(123))
  // ઇન્જેક્શન પરીક્ષણ માટે મોક (mock) પ્રોવાઇડ
  app.provide(...)
  // નિવેદનો (assertions) ચલાવો
  expect(result.foo.value).toBe(1)
  // જો જરૂર હોય તો onUnmounted હૂકને ટ્રિગર કરો
  app.unmount()
})

વધુ જટિલ કમ્પોઝેબલ્સ માટે, કમ્પોનન્ટ ટેસ્ટિંગ તકનીકોનો ઉપયોગ કરીને રેપર ઘટક સામે પરીક્ષણો લખીને તેનું પરીક્ષણ કરવું વધુ સરળ હોઈ શકે છે.