ما هو Behavior-Driven Development (BDD)؟

Question

Accepted Answer

**Behavior-Driven Development (BDD)** هو نهج يصف سلوك البرنامج بلغة **عادية منظمة** (Given-When-Then) يفهمها كل من الأشخاص التقنيين وغير التقنيين — مما يجسر الاتصال بين المطورين والمختبرين وأصحاب المصلحة في الأعمال، مع اشتقاق الاختبارات من هذه الأوصاف.

## ما هو BDD

```text
BDD focuses on describing BEHAVIOR in business-readable language:
  → write SCENARIOS in a structured natural-language format (Gherkin):
    GIVEN some initial context
    WHEN an action/event happens
    THEN an expected outcome occurs
  → these scenarios are both DOCUMENTATION and executable TESTS
→ Bridges devs, QA, and BUSINESS stakeholders with a shared, readable language.
```

## سيناريو Gherkin

```gherkin
Feature: User login
  Scenario: Successful login
    Given a registered user with valid credentials
    When they submit the login form
    Then they should see their dashboard
    And a welcome message should be displayed
```

```text
→ Tools (Cucumber, SpecFlow, Behave) map these plain-language steps to test code that runs
→ Non-technical stakeholders can READ and even help WRITE scenarios (shared understanding)
```

## BDD مقابل TDD

```text
TDD → developer-focused; tests drive code design; "is the code correct?" (unit level)
BDD → behavior/business-focused; scenarios describe FEATURES in shared language;
  "does it do what the business wants?" (collaboration, requirements as tests)
→ BDD extends TDD's idea toward COLLABORATION and business-readable specifications.
  (Given-When-Then = Arrange-Act-Assert in business terms.)
```

## لماذا يهم

فهم Behavior-Driven Development قيّم لأنه نهج مؤثر يؤكد على **التعاون والمواصفات القابلة للقراءة من قبل الأعمال**، لذا فهو معرفة مفيدة لفهم ممارسات الاختبار والمتطلبات.

الفكرة الأساسية لـ BDD — وصف سلوك البرنامج **بلغة عادية منظمة (Given-When-Then)** يمكن لكل من الأشخاص التقنيين وغير التقنيين فهمها — تعالج تحديًا حقيقيًا: الاتصال بين المطورين والمختبرين وأصحاب المصلحة في الأعمال حول ما يجب أن يفعله البرنامج.

بكتابة **السيناريوهات بلغة قابلة للقراءة من قبل الأعمال** التي تعمل كـ **توثيق واختبارات قابلة للتنفيذ** (من خلال أدوات مثل Cucumber)، ينشئ BDD فهمًا مشتركًا حيث يمكن لأصحاب المصلحة قراءة المواصفات بل والمساهمة في كتابتها، مما يقلل من سوء الفهم بشأن المتطلبات.

فهم **هيكل Given-When-Then** (Given سياق معين، When إجراء معين، Then نتيجة معينة — صيغة BDD لـ Arrange-Act-Assert) وكيف تخطط الأدوات هذه الخطوات بلغة عادية إلى رمز اختبار قابل للتشغيل هي المعرفة العملية.

فهم **BDD مقابل TDD** يوضح علاقتهما: TDD يركز على المطور (الاختبارات تقود تصميم الكود، "هل الكود صحيح؟")، بينما BDD يركز على السلوك/الأعمال (السيناريوهات التي تصف الميزات بلغة مشتركة، "هل يفعل ما تريده الأعمال؟") — مع توسيع BDD لفكرة TDD نحو التعاون والمواصفات القابلة للقراءة من قبل الأعمال.

فهم BDD يعكس الوعي بالممارسات التي تربط الاختبار بالمتطلبات والاتصال مع أصحاب المصلحة.

على الرغم من أنه لا تستخدم كل فريق BDD بشكل رسمي، فإن المفاهيم (السيناريوهات الموجهة للسلوك، التعاون، المواصفات القابلة للتنفيذ) مؤثرة وتستحق الفهم.

نظرًا لأن BDD هو نهج مؤثر يؤكد على التعاون ومواصفات السلوك القابلة للقراءة من قبل الأعمال (جسر الاتصال التقني والأعمال، مع السيناريوهات القابلة للتنفيذ)، وحيث أن فهمه وعلاقته بـ TDD يعكس نضج الاختبار والمتطلبات، فإن فهم Behavior-Driven Development معرفة قيمة وذات صلة — نهج ملحوظ يربط الاختبار بالتعاون والمتطلبات، مفيد لفهم كيف يمكن للفريق محاذاة الاختبارات التقنية مع المواصفات القابلة للقراءة من قبل الأعمال والاتصال مع أصحاب المصلحة.