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 نوٹیفکیشن وصول کرنا، سرور کا جواب۔ موبائل ایپلیکیشنز میں، یہ اکثر ViewMethod کو کال کرنے یا 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 ڈھونڈتا ہے اور منظرناموں کو عام instrumented ٹیسٹوں کے طور پر انجام دیتا ہے۔ نتائج گاہک کے لیے قابل فہم 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 ڈیوائس یا ایمولیٹر پر instrumented ٹیسٹوں کے طور پر چلتے ہیں۔ یہ JVM پر عام یونٹ ٹیسٹوں سے 10–50 گنا سست ہے۔ ایک بڑی Android ایپلیکیشن کے لیے ایک قبولیت ٹیسٹ 20–30 منٹ لگ سکتا ہے۔ سفارش کی جاتی ہے کہ BDD ٹیسٹ رات کو الگ CI جاب میں چلائے جائیں، جبکہ یونٹ ٹیسٹ ہر push پر چلیں۔ یہ حکمت عملی فیڈ بیک کی رفتار اور منظرنامے کی کوریج میں توازن پیدا کرتی ہے۔

ٹیم کی Gherkin تربیت

BDD میں منتقلی کے لیے نہ صرف ڈویلپرز بلکہ تجزیہ کاروں اور ٹیسٹرز کی تربیت بھی ضروری ہے۔ Gherkin ایک سادہ زبان ہے، لیکن اچھے منظرنامے لکھنے کے لیے مشق کی ضرورت ہے۔ ابتدائی افراد کی عام غلطیاں: بہت طویل منظرنامے (10 مراحل سے زیادہ)، Given-When-Then کو ملانا، کاروباری منظرناموں میں تکنیکی اصطلاحات کا استعمال۔ BDD Academy (2024) کے مطابق، ٹیموں کو BDD منظرنامے لکھنے میں پختگی حاصل کرنے کے لیے اوسطاً 4–6 سپرنٹ درکار ہوتے ہیں۔