BDD: ما هو، سيناريوهات السلوك وأطر العمل

ما هو BDD؟

Behavior-Driven Development هو تطور لـ TDD اقترحه Dan North في عام 2006 كإجابة لمشكلة صياغة الاختبارات. في TDD، يكتب المطور اختبارًا، لكن السؤال «ماذا نختبر بالضبط؟» يظل مفتوحًا. BDD يحل هذه المشكلة بتحويل التركيز من اختبار الكود إلى وصف سلوك النظام من وجهة نظر المستخدم.

الابتكار الرئيسي لـ BDD هو لغة مشتركة لجميع المشاركين في المشروع. يناقش المطورون والمختبرون والمحللون والعملاء السيناريوهات بلغة موحدة تعمل في الوقت نفسه كاختبار قابل للتنفيذ. هذا يلغي مشكلة «الهاتف المكسور» الكلاسيكية حيث تفقد المتطلبات معناها عند انتقالها من المحلل إلى المطور.

تاريخ نشأة BDD

صاغ Dan North BDD في عام 2006 في مقالته «Introducing BDD» على مدونة ThinkCode. لاحظ أن أسماء الاختبارات في 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 وتُخزن في دليل src/test/resources/features/ في مشاريع Android. يبدأ كل ملف بوصف 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 من التصميم القائم على المجال. يتكون كل سيناريو من ثلاثة أجزاء: الشروط المسبقة والإجراء والنتيجة المتوقعة. يتوافق هذا التنسيق طبيعيًا مع Arrange-Act-Assert من اختبارات الوحدة لكنه يستخدم لغة مفهومة للأعمال.

Given: السياق

تصف كتلة Given حالة النظام قبل بدء السيناريو: ما البيانات الموجودة، أي المكونات نشطة، في أي وضع يعمل التطبيق. في السياق المحمول، قد يكون هذا «المستخدم مسجل الدخول»، «سلة التسوق ليست فارغة» أو «الجهاز في وضع عدم الاتصال».

When: الإجراء

تصف كتلة When حدثًا يبدأه المستخدم أو النظام: الضغط على زر، استلام إشعار push، استجابة الخادم. في التطبيقات المحمولة، يتوافق هذا غالبًا مع استدعاء طريقة ViewModel أو النقر على عنصر واجهة.

Then: النتيجة

تصف كتلة Then التغيير المتوقع في الحالة: تغيير الشاشة، استدعاء API، تحديث قاعدة البيانات. يجب أن تكون الفحوصات في Then قابلة للقياس ولا لبس فيها — تصبح تأكيدات في الكود القابل للتنفيذ.

BDD و TDD: مقارنة المناهج

BDD و TDD غالبًا ما يتم الخلط بينهما، على الرغم من أنهما مستويان مختلفان من الانضباط. TDD هي تقنية تصميم على مستوى الكود: «كيفية كتابة التنفيذ». BDD هي تقنية مواصفات على مستوى المتطلبات: «ما يجب أن يفعله النظام».

التكامل في المشروع

أفضل المشاريع المحمولة تستخدم TDD على مستوى الفئات الفردية (طبقة المجال) و BDD على مستوى السيناريوهات (طبقة الميزات). هذا يوفر تغطية مزدوجة: TDD يضمن صحة التنفيذ، BDD يضمن صحة فهم المتطلبات. Google في ممارساتها الداخلية تستخدم مزيجًا من TDD و BDD لتطبيقات Android، كما هو مذكور في توثيق Android Testing (2024).

أدوات BDD للتطوير المحمول

يتضمن نظام BDD أطر عمل لجميع المنصات واللغات الشائعة للتطوير المحمول. يعتمد اختيار الأداة على مجموعة التقنيات ومستوى الأتمتة.

Cucumber لنظام Android

Cucumber هو إطار BDD الأكثر شيوعًا، ويعمل مع سيناريوهات Gherkin. لمشاريع Android، تُستخدم المكتبة io.cucumber:cucumber-android، التي تتكامل مع أدوات اختبار واجهة المستخدم Espresso و Compose Test. يدعم Cucumber Kotlin و Java، مما يجعله خيارًا عالميًا للاستوديوهات التي تستخدم كلتا اللغتين.

SpecFlow لنظام Xamarin

SpecFlow هو إطار BDD للنظام البيئي .NET، يُستخدم في مشاريع Xamarin.Forms و .NET MAUI. يتكامل SpecFlow مع NUnit و xUnit، وتُكتب step definitions الخاصة به بلغة C#. للمشاريع المحمولة، يسمح SpecFlow بإعادة استخدام السيناريوهات بين إصدارات Android و iOS للتطبيق على قاعدة كود مشتركة.

Quick/Nimble لنظام iOS

لتطوير iOS بلغة Swift، توجد أطر BDD Quick و Nimble. يوفر Quick DSL لوصف السيناريوهات بأسلوب describe/it، ويوفر Nimble أدوات مطابقة ببناء جملة قابل للقراءة. على الرغم من أن هذه الأطر لا تستخدم 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 بتنفيذ الاختبار. كل خطوة هي طريقة مع تعليق توضيحي يتوافق مع كلمة رئيسية في 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. يقوم بمسح ملفات .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 وكود الإنتاج. إذا غير المطورون APIs دون تحديث step definitions، تتوقف ملفات .feature عن التوافق مع التنفيذ. الحل هو تشغيل اختبارات BDD في خط أنابيب CI/CD وطلب الحالة الخضراء لطلبات الدمج. ممارسة «BDD كآلية حوكمة» موصوفة في توثيق Cucumber (2024) وهي معيار في الصناعة.

أداء اختبارات BDD

تُنفذ سيناريوهات BDD في Cucumber كاختبارات أدوات على جهاز Android أو محاكي. هذا أبطأ 10–50 مرة من اختبارات الوحدة العادية على JVM. اختبار قبول واحد قد يستغرق 20–30 دقيقة لتطبيق Android كبير. يُوصى بتشغيل اختبارات BDD في وظيفة CI منفصلة ليلاً، بينما تُشغل اختبارات الوحدة عند كل push. هذه الاستراتيجية توازن بين سرعة التغذية الراجعة وتغطية السيناريوهات.

تدريب الفريق على Gherkin

الانتقال إلى BDD يتطلب تدريبًا ليس فقط للمطورين ولكن أيضًا للمحللين والمختبرين. Gherkin لغة بسيطة، لكن كتابة سيناريوهات جيدة تتطلب ممارسة. أخطاء المبتدئين النموذجية: سيناريوهات طويلة جدًا (أكثر من 10 خطوات)، خلط Given-When-Then، استخدام مصطلحات تقنية في سيناريوهات الأعمال. وفقًا لـ BDD Academy (2024)، تحتاج الفرق في المتوسط من 4 إلى 6 سباقات لتحقيق النضج في كتابة سيناريوهات BDD.