BDD के बारे में 3 बातें जो कोई आपको नहीं बताता
आपका Cucumber suite चलने में चालीस मिनट लेता है। आप कोड की परतों को पढ़े बिना यह नहीं समझा सकते कि एक सिंगल feature file क्या टेस्ट करती है।
कई टीमें BDD इसलिए अपनाती हैं क्योंकि business stakeholders को टेस्ट पढ़ने की ज़रूरत होती है। फिर, वे stakeholders पढ़ना बंद कर देते हैं। अंत में, आपके पास मेंटेनेंस का एक बुरा सपना (nightmare) रह जाता है।
BDD के बारे में ये तीन सच्चाइयाँ हैं।
1. 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 को सरल रखें ताकि एक product manager उन्हें कुछ ही सेकंड में पढ़ सके।
2. Step definitions कोई dependency graph नहीं हैं
Step definitions को दूसरी step definitions को import न करने दें। इससे एक उलझा हुआ जाल (tangled web) बन जाता है। यदि एक step फेल होता है, तो यह पूरे state को खराब कर देता है।
इसका समाधान सरल है:
- अपने page objects को अपनी step definitions से अलग करें।
- एक shared domain layer का उपयोग करें।
- Step definitions को thin wrappers होना चाहिए जो domain objects को कॉल करें।
यह आपके steps को stateless बनाता है। आप बाकी सभी scenarios को तोड़े बिना अपने कोड के एक हिस्से को बदल सकते हैं।
3. BDD एक documentation प्रोजेक्ट है
BDD संचार (communication) के बारे में है, न कि केवल टेस्टिंग के बारे में। टेस्ट तो बस एक साइड इफेक्ट हैं।
यदि आप केवल test coverage या execution speed के लिए ऑप्टिमाइज़ करते हैं, तो आप मुख्य लक्ष्य खो देते हैं। आपकी feature files वह पहली चीज़ होनी चाहिए जिसे एक नया engineer आपके सिस्टम को समझने के लिए पढ़े।
यदि कोई व्यक्ति आपकी feature files पढ़कर आपके सिस्टम को नहीं समझ सकता, तो आपका BDD suite विफल हो गया है।
कल क्या करें:
- अपनी सबसे खराब feature file चुनें।
- Scenarios को तीन से पांच लाइन लंबे होने के लिए फिर से लिखें।
- डेटा को step definitions या factories में ले जाएँ।
- Step-to-step imports को domain objects से बदलें।
क्या आप केवल अपनी feature files का उपयोग करके पांच मिनट में किसी नए कर्मचारी (new hire) को अपना सिस्टम समझा सकते हैं? यदि नहीं, तो फिर से लिखना शुरू करें।
BDD के बारे में 3 बातें जो कोई आपको नहीं बताता, इससे पहले कि आपका Cucumber suite रखरखाव का दुःस्वप्न (maintenance nightmare) बन जाए
BDD (Behavior-Driven Development) सुनने में बहुत अच्छा लगता है। यह बिजनेस स्टेकहोल्डर्स और तकनीकी टीमों के बीच संचार की खाई को पाटने का वादा करता है। लेकिन, जैसे-जैसे आपका Cucumber suite बढ़ता है, चीजें जटिल होने लगती हैं।
यहाँ 3 बातें दी गई हैं जो अक्सर लोग आपको नहीं बताते:
1. Gherkin एक प्रोग्रामिंग भाषा नहीं है, लेकिन लोग इसे वैसे ही इस्तेमाल करते हैं
सबसे बड़ी गलती जो टीमें करती हैं, वह है Gherkin को कोड की तरह लिखना। यदि आपके Scenario बहुत अधिक तकनीकी विवरणों (technical details) से भरे हुए हैं, तो आपने BDD का मुख्य उद्देश्य ही खो दिया है।
Gherkin का उद्देश्य 'क्या' (what) को समझाना है, 'कैसे' (how) को नहीं। यदि आपके Scenarios में "I click on the submit button with ID #submit-btn" जैसे वाक्य हैं, तो आप गलत दिशा में जा रहे हैं। इसे "I submit the form" जैसा होना चाहिए। याद रखें, Gherkin को बिजनेस के लोगों द्वारा पढ़ा और समझा जा सकना चाहिए।
2. Step Definition का विस्फोट (Explosion)
जैसे-जैसे आपका टेस्ट सूट बढ़ता है, आपके Step Definitions की संख्या भी बढ़ती जाती है। बिना किसी योजना के, आप जल्द ही एक ऐसे मोड़ पर पहुँच जाएंगे जहाँ:
- एक ही क्रिया के लिए कई अलग-अलग स्टेप्स होंगे।
- स्टेप्स इतने अधिक होंगे कि नए स्टेप्स जोड़ते समय पुराने वाले को ढूंढना मुश्किल हो जाएगा।
- कोड में भारी मात्रा में डुप्लिकेशन (duplication) होगा।
इसे रोकने के लिए, आपको एक मजबूत 'Step Library' और सख्त दिशा-निर्देशों की आवश्यकता है ताकि स्टेप्स को पुन: प्रयोज्य (reusable) बनाया जा सके।
3. रखरखाव का बोझ (The Maintenance Burden)
BDD आपके टेस्ट ऑटोमेशन में एब्स्ट्रैक्शन (abstraction) की एक अतिरिक्त परत जोड़ता है। इसका मतलब है कि अब आपको दो चीजों का रखरखाव करना है:
- आपकी Step Definitions (कोड)।
- आपके Gherkin Scenarios (डॉक्यूमेंटेशन)।
यदि आपके Scenarios और कोड के बीच तालमेल नहीं है, तो आपका टेस्ट सूट एक 'maintenance nightmare' बन जाएगा। हर छोटे UI बदलाव के लिए आपको न केवल कोड, बल्कि शायद Gherkin फाइलों को भी अपडेट करना पड़ेगा। यह अतिरिक्त काम आपकी टीम की गति को धीमा कर सकता है।
निष्कर्ष:
BDD एक शक्तिशाली उपकरण है, लेकिन यह कोई जादू नहीं है। यदि आप इसे सही ढंग से लागू नहीं करते हैं, तो यह आपकी उत्पादकता बढ़ाने के बजाय उसे कम कर देगा। इसे केवल "टेस्ट लिखने का एक और तरीका" न समझें, बल्कि इसे "व्यवहार को परिभाषित करने का एक तरीका" समझें।