BDD વિશે એવી ૩ બાબતો જે તમને કોઈ કહેતું નથી

તમારી Cucumber suite ચલાવવામાં ચાલીસ મિનિટ લાગે છે. કોડના અનેક સ્તરો વાંચ્યા વગર તમે એક પણ feature file શું ટેસ્ટ કરે છે તે સમજાવી શકતા નથી.

ઘણી ટીમો BDD અપનાવે છે કારણ કે બિઝનેસ સ્ટેકહોલ્ડર્સ (stakeholders) ને ટેસ્ટ વાંચવાની જરૂર હોય છે. પછી, તે સ્ટેકહોલ્ડર્સ વાંચવાનું બંધ કરી દે છે. પરિણામે, તમારે મેન્ટેનન્સના кошાળનો સામનો કરવો પડે છે.

BDD વિશેના ત્રણ સત્યો અહીં છે.

૧. Gherkin એ પ્રોગ્રામિંગ લેંગ્વેજ નથી

Gherkin માં ટેસ્ટ સ્ક્રિપ્ટ્સ લખવાનું બંધ કરો. જો તમારા સિનારિયોઝ (scenarios) માં દરેક ક્લિક અને દરેક ફિલ્ડની યાદી હોય, તો તમે તે ખોટી રીતે કરી રહ્યા છો.

ખરાબ Gherkin:

  • Given વપરાશકર્તા "test@example.com" ઇમેઇલ દાખલ કરે છે
  • And વપરાશકર્તા "Password123!" પાસવર્ડ દાખલ કરે છે
  • And વપરાશકર્તા "Place Order" પર ક્લિક કરે છે

સારું Gherkin:

  • Given વપરાશકર્તા પાસે ખરીદવા માટે વસ્તુઓ તૈયાર છે
  • When વપરાશકર્તા માન્ય ક્રેડિટ કાર્ડથી પેમેન્ટ કરે છે
  • Then ઓર્ડર કન્ફર્મ થાય છે

"કેવી રીતે" (how) એ તમારા step definitions માં હોય છે. "શું" (what) એ તમારી feature files માં હોય છે. તમારી feature files ને સરળ રાખો જેથી પ્રોડક્ટ મેનેજર તેને સેકન્ડોમાં વાંચી શકે.

૨. Step definitions એ dependency graph નથી

Step definitions ને અન્ય step definitions ઇમ્પોર્ટ કરવા માટે ન બનાવો. આ એક જટિલ જાળ (tangled web) બનાવે છે. જો એક સ્ટેપ નિષ્ફળ જાય, તો તે સમગ્ર સ્ટેટ (state) ને બગાડી નાખે છે.

ઉકેલ સરળ છે:

  • તમારા page objects ને તમારા step definitions થી અલગ કરો.
  • એક shared domain layer નો ઉપયોગ કરો.
  • Step definitions એ domain objects ને કોલ કરતા પાતળા (thin) wrappers હોવા જોઈએ.

આ તમારા સ્ટેપ્સને stateless બનાવે છે. તમે અન્ય કોઈપણ સિનારિયોને તોડ્યા વગર તમારા કોડનો એક ભાગ બદલી શકો છો.

૩. BDD એ ડોક્યુમેન્ટેશન પ્રોજેક્ટ છે

BDD એ માત્ર ટેસ્ટિંગ વિશે નથી, પણ સંવાદ (communication) વિશે છે. ટેસ્ટ એ તેની આડઅસર છે.

જો તમે ફક્ત ટેસ્ટ કવરેજ અથવા એક્ઝિક્યુશન સ્પીડ માટે ઓપ્ટિમાઇઝ કરો છો, તો તમે મુખ્ય ધ્યેય ગુમાવી દેશો. તમારી સિસ્ટમ સમજવા માટે નવો એન્જિનિયર સૌથી પહેલા તમારી feature files વાંચતો હોવો જોઈએ.

જો કોઈ વ્યક્તિ તમારી feature files વાંચીને તમારી સિસ્ટમ સમજી શકતી નથી, તો તમારી BDD suite નિષ્ફળ ગઈ છે.

આવતીકાલે શું કરવું:

  • તમારી સૌથી ખરાબ feature file પસંદ કરો.
  • સિનારિયોઝને ત્રણ થી પાંચ લાઇન લાંબા હોય તે રીતે ફરીથી લખો.
  • ડેટાને step definitions અથવા factories માં ખસેડો.
  • step-to-step imports ને બદલે domain objects નો ઉપયોગ કરો.

શું તમે માત્ર તમારી feature files નો ઉપયોગ કરીને પાંચ મિનિટમાં નવા કર્મચારીને તમારી સિસ્ટમ સમજાવી શકો છો? જો નહીં, તો ફરીથી લખવાનું શરૂ કરો.

સ્ત્રોત: https://dev.to/qawalah/3-things-nobody-tells-you-about-bdd-before-your-cucumber-suite-becomes-a-maintenance-nightmare-9c7

વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi_