Given-When-Then: यह क्या है, परिदृश्य संरचना और उदाहरण

Given-When-Then क्या है?

Given-When-Then एक व्यवहार वर्णन पैटर्न है जिसे पहली बार Dan North ने 2006 में Behavior-Driven Development पद्धति के भाग के रूप में तैयार किया था। यह पैटर्न असंरचित परीक्षण परिदृश्य विवरणों की समस्या को हल करता है जो अक्सर पूर्वशर्तों, क्रियाओं और जाँचों को मनमाने क्रम में मिलाते हैं।

पैटर्न का मूल विचार तीन ब्लॉकों के बीच जिम्मेदारियों का पृथक्करण है। प्रत्येक ब्लॉक परिदृश्य के ठीक एक पहलू के लिए जिम्मेदार है: पहले की स्थिति, दौरान की घटना, और बाद का सत्यापन। यह परिदृश्य को पढ़ने योग्य, सत्यापन योग्य और स्वचालित बनाता है। Cucumber फ्रेमवर्क डेवलपर्स (2024) के शोध के अनुसार, जो परिदृश्य सख्ती से Given-When-Then पैटर्न का पालन करते हैं, उन्हें टीम के नए सदस्य को समझने में 42% कम समय लगता है।

पैटर्न की उत्पत्ति

Dan North ने तीन-भाग संरचना का विचार TDD में परीक्षणों के निरूपण और Test-by-Example पद्धति (Brian Marick द्वारा निर्मित) से उधार लिया। Marick ने उदाहरणों के माध्यम से आवश्यकताओं का वर्णन करने का प्रस्ताव रखा जो एक साथ परीक्षणों के रूप में काम करते हैं। Given-When-Then ने इस विचार को औपचारिक रूप दिया, असंरचित उदाहरणों को एक दोहराने योग्य पैटर्न में बदल दिया।

अनुप्रयोग का दायरा

Given-When-Then पैटर्न का उपयोग न केवल Gherkin में BDD परिदृश्यों में किया जाता है, बल्कि JUnit, XCTest और अन्य फ्रेमवर्क पर नियमित यूनिट परीक्षणों में भी किया जाता है। कोड में टिप्पणियाँ जो परीक्षण को तीन ब्लॉकों में विभाजित करती हैं, परीक्षण आधार की पठनीयता में सुधार के लिए एक सामान्य प्रथा है। Google अपनी पुस्तक “Software Engineering at Google” (2020) में इस दृष्टिकोण की अनुशंसा करता है।

तीन ब्लॉकों की संरचना

प्रत्येक Given-When-Then ब्लॉक की सख्ती से परिभाषित शब्दार्थ और भरने के नियम हैं। इन नियमों का उल्लंघन करने से ऐसे परिदृश्य बनते हैं जिन्हें स्वचालित या समझना मुश्किल होता है।

Given: पूर्वशर्तें

Given ब्लॉक परीक्षण की गई क्रिया को निष्पादित करने से पहले सिस्टम की स्थिति का वर्णन करता है। इसमें शामिल हैं: मौजूदा वस्तुएँ (उपयोगकर्ता, ऑर्डर, सेटिंग्स), सक्रिय स्थितियाँ (अधिकृत, नेटवर्क से जुड़ा), और डेटा के प्रारंभिक मान। प्रत्येक Given सत्यापन योग्य होना चाहिए — यदि सिस्टम की स्थिति Given से मेल नहीं खाती है, तो परिदृश्य को छोड़ दिया जाना चाहिए या परीक्षण वातावरण को पूर्व-कॉन्फ़िगर किया जाना चाहिए।

When: क्रिया

When ब्लॉक एक एकल घटना का वर्णन करता है जो परीक्षण के तहत व्यवहार शुरू करती है। यह एक विधि कॉल, एक बटन क्लिक, एक सूचना प्राप्त करना, या सर्वर प्रतिक्रिया हो सकती है। मुख्य नियम है प्रति परिदृश्य एक When. यदि आपको क्रियाओं के अनुक्रम को सत्यापित करने की आवश्यकता है, तो Whens की श्रृंखला के बजाय अलग-अलग परिदृश्य बनाएं।

// Given: परीक्षण डेटा बनाएँ
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: क्रिया निष्पादित करें
val result = PurchaseUseCase().buy(user, product)

// Then: परिणाम सत्यापित करें
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: अपेक्षित परिणाम

Then ब्लॉक सत्यापित करता है कि सिस्टम अपेक्षित स्थिति में पहुँच गया है। इसमें शामिल हैं: वापसी मान, वस्तुओं की स्थिति में परिवर्तन, बाह्य सेवाओं के कॉल (मॉक सत्यापन के माध्यम से), और UI परिवर्तन। प्रत्येक Then ब्लॉक में कई जाँचें हो सकती हैं, लेकिन वे सभी एक ही क्रिया से संबंधित होती हैं।

Given-When-Then और Arrange-Act-Assert

Given-When-Then और Arrange-Act-Assert (AAA) एक ही तीन-भाग पैटर्न के दो प्रकार हैं, लेकिन विभिन्न लक्षित दर्शकों के साथ। उनके अंतर को समझने से किसी विशिष्ट कार्य के लिए सही प्रारूप चुनने में मदद मिलती है।

Given-When-Then का उपयोग कब करें

Given-When-Then पैटर्न उन परिदृश्यों के लिए इष्टतम है जिन पर ग्राहकों या विश्लेषकों के साथ चर्चा की जाती है: फीचर स्वीकृति मानदंड, उपयोग के मामले, रिग्रेशन जाँच। Gherkin सिंटैक्स प्रोग्रामिंग ज्ञान के बिना ऐसे परिदृश्य लिखने की अनुमति देता है।

Arrange-Act-Assert का उपयोग कब करें

Arrange-Act-Assert यूनिट परीक्षणों के लिए स्वाभाविक विकल्प है जो किसी विशिष्ट विधि या वर्ग को सत्यापित करते हैं। AAA प्रारूप को अतिरिक्त फ्रेमवर्क की आवश्यकता नहीं है और यह किसी भी प्रोग्रामिंग भाषा में काम करता है। iOS विकास के लिए, Apple XCTest दस्तावेज़ीकरण (2024) में AAA की अनुशंसा करता है।

Kotlin में परिदृश्यों के उदाहरण

आइए Android एप्लिकेशन के लिए Kotlin में Given-When-Then के व्यावहारिक उदाहरण देखें। पहला उदाहरण MockK का उपयोग करके शॉपिंग कार्ट का परीक्षण करता है। दूसरा पुश सूचना तर्क का परीक्षण करता है।

उदाहरण 1: शॉपिंग कार्ट

class CartTest {
    fun `apply discount when total exceeds threshold`() {
        // Given
        val cart = Cart()
        cart.addItem(Item("Laptop", price = 1000.0))
        cart.addItem(Item("Mouse", price = 50.0))
        val discount = DiscountCalculator(0.1)

        // When
        val total = discount.applyIfEligible(cart)

        // Then
        assertEquals(945.0, total)
        assertTrue("Discount was not applied", total < 1050.0)
    }
}

उदाहरण 2: कोरूटीन के साथ पुश सूचनाएँ

दूसरा उदाहरण अतुल्यकालिक कोड के साथ Given-When-Then प्रदर्शित करता है। यहाँ Given Firebase Cloud Messaging की स्थिति सेट करता है, When एक पुश सूचना प्राप्त करता है, और Then प्रसंस्करण की जाँच करता है।

class PushNotificationTest {
    fun `handle push notification when app in background`() = runTest {
        // Given
        val prefs = mockk<SharedPreferences>()
        every { prefs.getString("token", null) } returns "fcm-token-abc"
        val handler = PushHandler(prefs)

        // When
        val data = RemoteMessage().apply {
            putData("type", "order_update")
            putData("order_id", "123")
        }
        val result = handler.handleNotification(data)

        // Then
        assertEquals(NotificationAction.OpenOrder("123"), result)
    }
}

उदाहरण 3: प्राधिकरण के लिए Gherkin परिदृश्य

तीसरा उदाहरण Gherkin में एक BDD परिदृश्य है, जो स्वीकृति परीक्षणों के संदर्भ में Given-When-Then दिखाता है:

Feature: User Authorization
  Scenario: User cannot login with expired token
    Given the user has an expired refresh token
    When they try to access the protected profile screen
    Then they should see the login screen
    And the app should clear all cached data

परिदृश्य लिखने के सर्वोत्तम अभ्यास

Given-When-Then के प्रभावी अनुप्रयोग के लिए कई सिद्ध प्रथाओं का पालन आवश्यक है। वे परिदृश्यों की पठनीयता, रखरखाव और स्वचालन क्षमता सुनिश्चित करते हैं।

प्रति परिदृश्य एक When

सख्त नियम: एक परिदृश्य — एक क्रिया. यदि आपको कई Whens के अनुक्रम को सत्यापित करने की आवश्यकता है, तो कई परिदृश्य बनाएं जहाँ पिछले का परिणाम अगले की पूर्वशर्त बन जाता है। यह परिदृश्य को परमाणु और स्पष्ट बनाता है।

Given में विशिष्ट डेटा से बचें

Given को सार का वर्णन करना चाहिए, विशिष्ट संख्याओं का नहीं। “Given उपयोगकर्ता इवानोव 500 रूबल के शेष के साथ” के बजाय “Given पर्याप्त शेष वाला उपयोगकर्ता।” विशिष्ट डेटा को Examples तालिका के साथ Scenario Outline में ले जाया जाता है। यह परिदृश्य को सार्वभौमिक और पुन: प्रयोज्य बनाता है।

• Then को मापने योग्य कथनों के रूप में लिखें — “उपयोगकर्ता को लॉगिन स्क्रीन देखनी चाहिए”, न कि “उपयोगकर्ता को पुनर्निर्देशित किया जाना चाहिए”
• समान चरणों के लिए And का उपयोग करें — यदि कई Given की आवश्यकता है, तो उन्हें And के साथ संयोजित करें, दूसरा Given न बनाएँ
• अमूर्तता स्तरों को न मिलाएँ — Given-When-Then एक स्तर पर होना चाहिए: या तो व्यावसायिक या तकनीकी, मिश्रित नहीं
• परिदृश्य के कारण का दस्तावेज़ीकरण करें — .feature फ़ाइल की शुरुआत में व्यावसायिक नियम का वर्णन करने वाली टिप्पणी संदर्भ प्रदान करने में मदद करती है

CI/CD पाइपलाइन में Given-When-Then

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

परिदृश्यों का स्वचालित निष्पादन

Android के लिए Cucumber पर BDD परिदृश्य Gradle कार्य ./gradlew cucumber के माध्यम से चलाए जाते हैं। iOS (Quick/Nimble) के लिए — xcodebuild test के माध्यम से। CI सिस्टम (GitHub Actions, GitLab CI, Bitrise) में, BDD परीक्षण एमुलेटर या वास्तविक उपकरणों पर निष्पादित होते हैं। रिपोर्ट प्रबंधकों के लिए समझने योग्य HTML प्रारूप में बनाई जाती है: हरे परिदृश्य — पास, लाल — विफलता के साथ विफल चरण का संकेत।

रिपॉजिटरी में जीवंत दस्तावेज़ीकरण

.feature फ़ाइलें कोड के साथ रिपॉजिटरी में संग्रहीत की जाती हैं और कोड समीक्षा से गुजरती हैं। विकास शुरू होने से पहले एक विश्लेषक नए परिदृश्यों के साथ मर्ज अनुरोध बनाता है (BDD-first)। डेवलपर इन परिदृश्यों को पास कराने के लिए स्टेप डेफ़िनिशन और कार्यान्वयन लिखता है। जब सभी परिदृश्य पास हो जाते हैं — कार्यक्षमता तैयार है। Gojko Adzic की पुस्तक “Specification by Example” (2011) में वर्णित यह दृष्टिकोण, आवश्यकताओं को एक निष्पादन योग्य आर्टिफैक्ट में बदल देता है।