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 بلاک تصدیق کرتا ہے کہ سسٹم متوقع حالت میں منتقل ہو گیا ہے۔ اس میں شامل ہیں: واپسی کی اقدار، اشیاء کی حالت میں تبدیلیاں، بیرونی خدمات کو کالز (مصوری تصدیق کے ذریعے) اور یوزر انٹرفیس میں تبدیلیاں۔ ہر 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 صارف Ivanov 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) میں بیان کیا گیا ہے، ضروریات کو ایک قابل عمل آرٹیفیکٹ میں بدل دیتا ہے۔