BDD: क्या है, व्यवहार परिदृश्य और फ्रेमवर्क

BDD क्या है?

Behavior-Driven Development TDD का एक विकास है जिसे Dan North ने 2006 में परीक्षण निर्माण की समस्या के उत्तर के रूप में प्रस्तावित किया था। TDD में, डेवलपर एक परीक्षण लिखता है, लेकिन प्रश्न “वास्तव में क्या परीक्षण करें?” खुला रहता है। BDD इस समस्या को कोड परीक्षण से ध्यान हटाकर सिस्टम व्यवहार का वर्णन उपयोगकर्ता के दृष्टिकोण से करके हल करता है।

BDD का मुख्य नवाचार सभी परियोजना प्रतिभागियों के लिए एक सामान्य भाषा है। डेवलपर्स, परीक्षक, विश्लेषक और ग्राहक एक एकीकृत भाषा में परिदृश्यों पर चर्चा करते हैं जो साथ ही एक निष्पादन योग्य परीक्षण के रूप में कार्य करती है। यह क्लासिक “खराब फ़ोन” समस्या को समाप्त करता है जहाँ विश्लेषक से डेवलपर तक पहुँचने पर आवश्यकताएँ अपना अर्थ खो देती हैं।

BDD के उद्भव का इतिहास

Dan North ने 2006 में ThinkCode ब्लॉग पर अपने लेख “Introducing BDD” में BDD तैयार किया। उन्होंने देखा कि TDD में परीक्षणों के नाम अक्सर कार्यान्वयन शब्दों (“testAddUser”) में तैयार किए जाते हैं न कि व्यवहार शब्दों (“उपयोगकर्ता को ईमेल से पंजीकरण करने में सक्षम होना चाहिए”) में। BDD ने “test” शब्द को “should” और “assert” को “expect” से बदल दिया, ध्यान को उपयोगकर्ता मूल्य पर केंद्रित कर दिया।

BDD एक संचार अभ्यास के रूप में

कैम्ब्रिज विश्वविद्यालय के अध्ययन (2021) के अनुसार, ग्राहक संचार में BDD परिदृश्यों का उपयोग करने वाली परियोजनाएँ पारंपरिक टेक्स्ट दस्तावेज़ विनिर्देशों की तुलना में आवश्यकता त्रुटियों को 35% कम करती हैं। निष्पादन योग्य परिदृश्य अस्पष्ट निरूपण की अनुमति नहीं देते — प्रत्येक Given-When-Then या तो पास होता है या फेल।

Gherkin भाषा और सिंटैक्स

Gherkin एक डोमेन-विशिष्ट भाषा है जिसका उपयोग Cucumber और SpecFlow फ्रेमवर्क व्यवहार परिदृश्यों का वर्णन करने के लिए करते हैं। Gherkin परिदृश्यों को संरचित करने के लिए इंडेंटेशन और कीवर्ड का उपयोग करता है, जबकि यह तकनीकी पृष्ठभूमि के बिना लोगों के लिए पढ़ने योग्य रहता है।

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Gherkin कीवर्ड

Gherkin कई बुनियादी कीवर्ड परिभाषित करता है। Feature कार्यक्षमता का वर्णन करता है, Scenario एक विशिष्ट परिदृश्य का वर्णन करता है, Given पूर्व शर्तों का वर्णन करता है, When क्रिया का वर्णन करता है, Then अपेक्षित परिणाम का वर्णन करता है। इसके अतिरिक्त, And और But का उपयोग कई शर्तों को संयोजित करने के लिए किया जाता है।

.feature फ़ाइल संरचना

Gherkin फ़ाइलों का एक्सटेंशन .feature होता है और ये Android प्रोजेक्ट्स में src/test/resources/features/ निर्देशिका में संग्रहीत होती हैं। प्रत्येक फ़ाइल Feature विवरण से शुरू होती है, जिसके बाद एक या अधिक Scenario होते हैं। पैरामीटरीकरण के लिए Examples तालिकाओं के साथ Scenario Outline का उपयोग किया जाता है — यह विभिन्न डेटा के साथ एक ही परिदृश्य को चलाने की अनुमति देता है।

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Given-When-Then प्रारूप

Given-When-Then परिदृश्यों का वर्णन करने के लिए एक संरचनात्मक पैटर्न है, जिसे BDD द्वारा डोमेन-ड्रिवन डिज़ाइन से अपनाया गया है। प्रत्येक परिदृश्य तीन भागों से बना होता है: पूर्व शर्तें, क्रिया और अपेक्षित परिणाम। यह प्रारूप स्वाभाविक रूप से यूनिट परीक्षण के Arrange-Act-Assert से मेल खाता है लेकिन व्यवसाय-अनुकूल भाषा का उपयोग करता है।

Given: संदर्भ

Given ब्लॉक परिदृश्य शुरू होने से पहले सिस्टम की स्थिति का वर्णन करता है: कौन सा डेटा मौजूद है, कौन से घटक सक्रिय हैं, एप्लिकेशन किस मोड में है। मोबाइल संदर्भ में, यह “उपयोगकर्ता लॉग इन है”, “कार्ट खाली नहीं है” या “डिवाइस ऑफलाइन मोड में है” हो सकता है।

When: क्रिया

When ब्लॉक उपयोगकर्ता या सिस्टम द्वारा ट्रिगर की गई घटना का वर्णन करता है: बटन दबाना, push सूचना प्राप्त करना, सर्वर प्रतिक्रिया। मोबाइल एप्लिकेशन में, यह अक्सर ViewModel विधि को कॉल करने या UI तत्व पर क्लिक करने से मेल खाता है।

Then: परिणाम

Then ब्लॉक अपेक्षित स्थिति परिवर्तन का वर्णन करता है: स्क्रीन परिवर्तन, API कॉल, डेटाबेस अपडेट। Then में जाँच मापने योग्य और स्पष्ट होनी चाहिए — वे निष्पादन योग्य कोड में assertions बन जाती हैं।

BDD और TDD: दृष्टिकोणों की तुलना

BDD और TDD अक्सर भ्रमित होते हैं, हालाँकि ये अनुशासन के विभिन्न स्तर हैं। TDD कोड स्तर पर एक डिज़ाइन तकनीक है: “कार्यान्वयन कैसे लिखें”। BDD आवश्यकता स्तर पर एक विनिर्देश तकनीक है: “सिस्टम को क्या करना चाहिए”।

परियोजना में पूरकता

सर्वश्रेष्ठ मोबाइल प्रोजेक्ट व्यक्तिगत क्लास स्तर (डोमेन लेयर) पर TDD और परिदृश्य स्तर (फीचर लेयर) पर BDD का उपयोग करते हैं। यह दोहरी कवरेज प्रदान करता है: TDD कार्यान्वयन सटीकता सुनिश्चित करता है, BDD आवश्यकता समझ की सटीकता सुनिश्चित करता है। Google अपने आंतरिक अभ्यास में Android एप्लिकेशन के लिए TDD और BDD के संयोजन का उपयोग करता है, जैसा कि Android Testing दस्तावेज़ीकरण (2024) में बताया गया है।

मोबाइल डेवलपमेंट के लिए BDD उपकरण

BDD पारिस्थितिकी तंत्र में सभी लोकप्रिय मोबाइल डेवलपमेंट प्लेटफ़ॉर्म और भाषाओं के लिए फ्रेमवर्क शामिल हैं। उपकरण का चुनाव तकनीकी स्टैक और ऑटोमेशन स्तर पर निर्भर करता है।

Android के लिए Cucumber

Cucumber सबसे लोकप्रिय BDD फ्रेमवर्क है, जो Gherkin परिदृश्यों के साथ काम करता है। Android प्रोजेक्ट्स के लिए, io.cucumber:cucumber-android लाइब्रेरी का उपयोग किया जाता है, जो Espresso और Compose Test UI परीक्षण उपकरणों के साथ एकीकृत होती है। Cucumber Kotlin और Java का समर्थन करता है, जो इसे दोनों भाषाओं का उपयोग करने वाले स्टूडियो के लिए एक सार्वभौमिक विकल्प बनाता है।

Xamarin के लिए SpecFlow

SpecFlow .NET पारिस्थितिकी तंत्र के लिए एक BDD फ्रेमवर्क है, जिसका उपयोग Xamarin.Forms और .NET MAUI प्रोजेक्ट्स में किया जाता है। SpecFlow NUnit और xUnit के साथ एकीकृत होता है, और इसकी step definitions C# में लिखी जाती हैं। मोबाइल प्रोजेक्ट्स के लिए, SpecFlow साझा कोडबेस पर एप्लिकेशन के Android और iOS संस्करणों के बीच परिदृश्यों को पुनः उपयोग करने की अनुमति देता है।

iOS के लिए Quick/Nimble

Swift में iOS डेवलपमेंट के लिए, BDD फ्रेमवर्क Quick और Nimble मौजूद हैं। Quick describe/it शैली में परिदृश्यों का वर्णन करने के लिए DSL प्रदान करता है, और Nimble पढ़ने योग्य सिंटैक्स के साथ matchers प्रदान करता है। हालाँकि ये फ्रेमवर्क सीधे Gherkin का उपयोग नहीं करते, वे BDD सिद्धांत को लागू करते हैं: पूरी टीम के लिए समझने योग्य भाषा में व्यवहार का वर्णन करना।

BDD परिदृश्य और कोड उदाहरण

आइए एक Android प्रोजेक्ट में BDD का पूरा उदाहरण देखें: ऑर्डर चेकआउट परिदृश्य। पहले हम Gherkin परिदृश्य लिखते हैं, फिर Kotlin में step definitions।

BDD कार्य सिद्धांत: three amigos

BDD पद्धति three amigos बैठक पर आधारित है — तीन भूमिकाएँ: डेवलपर, परीक्षक और विश्लेषक। वे डेवलपमेंट शुरू होने से पहले एक साथ परिदृश्य लिखते हैं, आवश्यकताओं की साझा समझ स्थापित करते हैं। यदि तीन प्रतिभागियों में से एक भी परिदृश्य को नहीं समझता, तो इसका मतलब है कि आवश्यकता अस्पष्ट रूप से तैयार की गई है। यह अभ्यास पुस्तक “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) में वर्णित है और परिपक्व टीमों में BDD प्रक्रिया का एक अनिवार्य हिस्सा है।

Gherkin परिदृश्य: ऑर्डर चेकआउट

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Kotlin में Step Definitions

Step definitions वह कोड है जो Gherkin परिदृश्यों को परीक्षण कार्यान्वयन से जोड़ता है। प्रत्येक चरण एक एनोटेशन वाली विधि है जो Gherkin कीवर्ड से मेल खाती है।

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Cucumber Android के साथ एकीकरण

Android प्रोजेक्ट में BDD परीक्षण चलाने के लिए, CucumberAndroidJUnitRunner का उपयोग किया जाता है। यह संसाधनों में .feature फ़ाइलों को स्कैन करता है, रेगुलर एक्सप्रेशन द्वारा संबंधित step definitions ढूँढता है, और परिदृश्यों को सामान्य इंस्ट्रूमेंटेड परीक्षणों के रूप में निष्पादित करता है। परिणाम ग्राहक के लिए समझने योग्य HTML रिपोर्ट में स्वरूपित होते हैं।

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

मोबाइल प्रोजेक्ट्स में BDD लागू करने की चुनौतियाँ

मोबाइल डेवलपमेंट में BDD लागू करना कई व्यावहारिक कठिनाइयों से जुड़ा है। इन समस्याओं को समझने से टीमों को निराशा से बचने और एक स्थायी BDD प्रक्रिया बनाने में मदद मिलती है।

.feature फ़ाइलों का रखरखाव

मुख्य समस्या Gherkin परिदृश्यों और प्रोडक्शन कोड के बीच डीसिंक्रनाइज़ेशन है। यदि डेवलपर्स step definitions को अपडेट किए बिना APIs बदलते हैं, तो .feature फ़ाइलें कार्यान्वयन से मेल नहीं खातीं। समाधान CI/CD पाइपलाइन में BDD परीक्षण चलाना और मर्ज अनुरोधों के लिए हरी स्थिति की आवश्यकता है। “BDD as a gating mechanism” का अभ्यास Cucumber दस्तावेज़ीकरण (2024) में वर्णित है और उद्योग में एक मानक है।

BDD परीक्षण प्रदर्शन

Cucumber में BDD परिदृश्य Android डिवाइस या एमुलेटर पर इंस्ट्रूमेंटेड परीक्षणों के रूप में चलते हैं। यह JVM पर सामान्य यूनिट परीक्षणों से 10–50 गुना धीमा है। एक बड़े Android एप्लिकेशन के लिए एक स्वीकृति परीक्षण में 20–30 मिनट लग सकते हैं। BDD परीक्षणों को रात में एक अलग CI जॉब में चलाने की सिफारिश की जाती है, जबकि यूनिट परीक्षण हर push पर चलते हैं। यह रणनीति फीडबैक गति और परिदृश्य कवरेज को संतुलित करती है।

टीम को Gherkin में प्रशिक्षण

BDD में संक्रमण के लिए न केवल डेवलपर्स बल्कि विश्लेषकों और परीक्षकों के प्रशिक्षण की आवश्यकता होती है। Gherkin एक सरल भाषा है, लेकिन अच्छे परिदृश्य लिखने के लिए अभ्यास की आवश्यकता होती है। शुरुआती लोगों की सामान्य गलतियाँ: बहुत लंबे परिदृश्य (10 से अधिक चरण), Given-When-Then को मिलाना, व्यावसायिक परिदृश्यों में तकनीकी शब्दों का उपयोग करना। BDD Academy (2024) के अनुसार, टीमों को BDD परिदृश्य लिखने में परिपक्वता प्राप्त करने के लिए औसतन 4–6 स्प्रिंट की आवश्यकता होती है।