BDD: چیست، سناریوهای رفتاری و فریم‌ورک‌ها

BDD چیست؟

Behavior-Driven Development — تکامل TDD است که توسط Dan North در سال ۲۰۰۶ به عنوان پاسخی به مشکل فرمول‌بندی تست‌ها ارائه شد. در TDD توسعه‌دهنده تست می‌نویسد، اما سوال «دقیقاً چه چیزی را تست کنیم؟» باز می‌ماند. BDD این مشکل را حل می‌کند و تمرکز را از تست کد به توصیف رفتار سیستم از دیدگاه کاربر تغییر می‌دهد.

نوآوری کلیدی BDD — زبان مشترک برای همه شرکت‌کنندگان پروژه است. توسعه‌دهندگان، تست‌کنندگان، تحلیل‌گران و مشتریان سناریوها را به زبانی واحد讨论 می‌کنند که همزمان یک تست قابل اجرا است. این مشکل کلاسیک «تلفن خراب» را از بین می‌برد، زمانی که نیازها در انتقال از تحلیل‌گر به توسعه‌دهنده معنی خود را از دست می‌دهند.

تاریخچه پیدایش BDD

Dan North BDD را در سال ۲۰۰۶ در مقاله «Introducing BDD» در وبلاگ ThinkCode فرمول‌بندی کرد. او متوجه شد که نام تست‌ها در TDD اغلب بر حسب پیاده‌سازی («testAddUser») فرمول‌بندی می‌شوند، نه بر حسب رفتار («user should be able to register with email»). BDD کلمه «test» را با «should» و «assert» را با «expect» جایگزین کرد و تمرکز را به ارزش برای کاربر منتقل کرد.

BDD به عنوان یک رویه ارتباطی

بر اساس تحقیق Cambridge University (۲۰۲۱)، پروژه‌هایی که از سناریوهای BDD در ارتباط با مشتری استفاده می‌کنند، تعداد خطاها در نیازها را در مقایسه با مشخصات سنتی در اسناد متنی ۳۵٪ کاهش می‌دهند. سناریوهای قابل اجرا اجازه عبارات مبهم را نمی‌دهند — هر 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 می‌آید. برای پارامترسازی از Scenario Outline با جداول Examples استفاده می‌شود — این امکان اجرای یک سناریو با داده‌های مختلف را فراهم می‌کند.

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 از domain-driven design گرفته شده است. هر سناریو از سه بخش تشکیل شده است: پیش‌شرط‌ها، اقدام و نتیجه مورد انتظار. این قالب به طور طبیعی با Arrange-Act-Assert از تست واحد مطابقت دارد، اما از زبان قابل فهم برای کسب‌وکار استفاده می‌کند.

Given: زمینه

بلوک Given وضعیت سیستم را قبل از شروع سناریو توصیف می‌کند: چه داده‌هایی وجود دارند، چه اجزایی فعال هستند، برنامه در چه حالتی کار می‌کند. در زمینه موبایل این می‌تواند «کاربر وارد شده است»، «سبد خرید خالی نیست» یا «دستگاه در حالت آفلاین است» باشد.

When: اقدام

بلوک When رویدادی را که توسط کاربر یا سیستم شروع می‌شود توصیف می‌کند: فشار دکمه، دریافت اعلان push، پاسخ سرور. در برنامه‌های موبایل این اغلب با فراخوانی متد ViewModel یا کلیک روی عنصر UI مطابقت دارد.

Then: نتیجه

بلوک Then تغییر وضعیت مورد انتظار را توصیف می‌کند: تغییر صفحه، فراخوانی API، به‌روزرسانی پایگاه داده. بررسی‌ها در Then باید قابل اندازه‌گیری و بدون ابهام باشند — آنها به assertions در کد قابل اجرا تبدیل می‌شوند.

BDD و TDD: مقایسه رویکردها

BDD و TDD اغلب اشتباه گرفته می‌شوند، اگرچه سطوح مختلفی از انضباط هستند. TDD — تکنیک طراحی در سطح کد: «چگونه پیاده‌سازی را بنویسیم». BDD — تکنیک مشخصات در سطح نیازها: «سیستم باید چه کاری انجام دهد».

تکمیل متقابل در پروژه

بهترین پروژه‌های موبایل از TDD در سطح کلاس‌های جداگانه (لایه domain) و BDD در سطح سناریوها (لایه feature) استفاده می‌کنند. این پوشش دوگانه را فراهم می‌کند: TDD correctness پیاده‌سازی را تضمین می‌کند، BDD — correctness درک نیازها را. Google در رویه داخلی خود از ترکیب TDD و BDD برای برنامه‌های Android استفاده می‌کند، همانطور که در مستندات Android Testing (2024) اشاره شده است.

ابزارهای BDD برای توسعه موبایل

اکوسیستم BDD شامل فریم‌ورک‌هایی برای همه پلتفرم‌ها و زبان‌های محبوب توسعه موبایل است. انتخاب ابزار به stack فناوری و سطح اتوماسیون بستگی دارد.

Cucumber برای Android

Cucumber — محبوب‌ترین فریم‌ورک BDD است که با سناریوهای Gherkin کار می‌کند. برای پروژه‌های Android از کتابخانه io.cucumber:cucumber-android استفاده می‌شود که با ابزارهای تست UI Espresso و Compose Test یکپارچه می‌شود. Cucumber از Kotlin و Java پشتیبانی می‌کند، که آن را به انتخابی جهانی برای استودیوهایی تبدیل می‌کند که از هر دو زبان استفاده می‌کنند.

SpecFlow برای Xamarin

SpecFlow — فریم‌ورک BDD برای اکوسیستم .NET است که در پروژه‌های Xamarin.Forms و .NET MAUI استفاده می‌شود. SpecFlow با NUnit و xUnit یکپارچه می‌شود و stepهای آن (step definitions) به زبان C# نوشته می‌شوند. برای پروژه‌های موبایل SpecFlow امکان استفاده مجدد از سناریوها بین نسخه‌های Android و iOS برنامه را بر روی پایه کد مشترک فراهم می‌کند.

Quick/Nimble برای iOS

برای توسعه iOS به زبان Swift فریم‌ورک‌های BDD Quick و Nimble وجود دارند. Quick یک DSL برای توصیف سناریوها به سبک describe/it ارائه می‌دهد و Nimble — matcherهایی با نحو قابل خواندن. اگرچه این فریم‌ورک‌ها مستقیماً از Gherkin استفاده نمی‌کنند، اصل BDD را پیاده‌سازی می‌کنند: توصیف رفتار به زبان قابل فهم برای کل تیم.

نمونه‌های سناریوهای BDD و کد

بیایید یک مثال کامل از BDD در پروژه Android را بررسی کنیم: سناریوی ثبت سفارش. ابتدا سناریوی Gherkin را می‌نویسیم، سپس — step definitions به زبان Kotlin.

اصل کار 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

Step definitions در Kotlin

Step definitions — کدی است که سناریوی Gherkin را با پیاده‌سازی تست متصل می‌کند. هر step یک متد با annotation متناظر با کلمه کلیدی 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

برای اجرای تست‌های BDD در پروژه Android از CucumberAndroidJUnitRunner استفاده می‌شود. این runner فایل‌های .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 و کد production است. اگر توسعه‌دهندگان API را تغییر دهند بدون به‌روزرسانی step definitions، فایل‌های .feature با پیاده‌سازی مطابقت ندارند. راه حل — اجرای تست‌های BDD در pipeline CI/CD و نیاز به وضعیت سبز برای merge request. رویه «BDD as a gating mechanism» در مستندات Cucumber (2024) توضیح داده شده است و استانداردی در صنعت است.

عملکرد تست‌های BDD

سناریوهای BDD در Cucumber از طریق تست‌های ابزاری بر روی دستگاه Android یا شبیه‌ساز اجرا می‌شوند. این ۱۰–۵۰ برابر کندتر از تست‌های واحد معمولی روی JVM است. یک تست پذیرش می‌تواند برای یک برنامه Android بزرگ ۲۰–۳۰ دقیقه طول بکشد. توصیه می‌شود تست‌های BDD را در یک job CI جداگانه قرار داده و آنها را در شب اجرا کنید، و تست‌های واحد — در هر push. چنین استراتژی سرعت بازخورد و پوشش سناریوها را متعادل می‌کند.

آموزش Gherkin به تیم

انتقال به BDD نیاز به آموزش نه تنها توسعه‌دهندگان، بلکه تحلیل‌گران و تست‌کنندگان دارد. Gherkin زبان ساده‌ای است، اما نوشتن سناریوهای خوب نیاز به تمرین دارد. خطاهای معمول مبتدیان: سناریوهای خیلی طولانی (بیش از ۱۰ step)، مخلوط کردن Given-When-Then، استفاده از اصطلاحات فنی در سناریوهای کسب‌وکار. بر اساس BDD Academy (2024)، تیم‌ها به طور متوسط به ۴–۶ اسپرینت نیاز دارند تا به بلوغ در نوشتن سناریوهای BDD برسند.