التطوير الموجَّه بالسلوك وGherkin

لماذا يهم

كثير من العيوب المكلفة في ميزات الأعمال ليست زلات برمجة بل سوء فهم: قرأ المطور «⁦200.00⁩ فأكثر» على أنها «أكثر من ⁦200.00⁩»، أو لم يقرر أحد ما الذي يحدث لرمز منتهي الصلاحية. ويعالج هذا التطوير تلك الكلفة من منبعها: فالحوار حول أمثلة محددة قبل كتابة أي شيفرة يكشف القراءات المختلفة والقواعد الناقصة وهي ما زالت رخيصة الإصلاح، ولذلك فهو من أبكر صور الاختبار الساكن (Static Testing) لدى الفريق.

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

يبدأ BDD بحوار: «الأصدقاء الثلاثة»

تصف Cucumber، وهي من أشهر أدوات BDD، العمل اليومي بهذا الأسلوب بثلاث ممارسات تتكرر مع كل تغيير صغير. الاكتشاف (Discovery): يناقش الفريق أمثلة محددة للسلوك الجديد ويتفق على تفاصيله. والصياغة (Formulation): تُكتب الأمثلة المتفق عليها سيناريوهاتِ Gherkin، ويتحقق من اتفقوا عليها من أن الصياغة ما زالت تقول ما قصدوه. والأتمتة (Automation): تُربط السيناريوهات بالشيفرة لتعمل على النظام، ويُفضَّل أن يحدث ذلك قبل بناء الميزة ليوجّه التطوير. باختصار: ما يمكن أن يفعله النظام، وما ينبغي أن يفعله، وما يفعله فعلاً.

يحدث الاكتشاف عادةً في اجتماع قصير لكل قصة أثناء تحسين قائمة العمل (Backlog Refinement)، قبل بدء التطوير. وتسميه فرق كثيرة «الأصدقاء الثلاثة» (Three Amigos) لأنه يجمع ثلاثة منظورات: الأعمال (مالك المنتج أو محلل الأعمال، صاحب المشكلة والقواعد)، والتطوير (من يعرف كيف يمكن البناء وما الصعب تقنياً)، والاختبار (من يسأل ما الذي قد يسوء وأي الأمثلة تُظهر ذلك). والمهم هو المنظورات الثلاثة لا عدد الحاضرين، فقد ينضم مصمم أو مطور ثانٍ.

ومن الطرق الشائعة لإدارة هذا الاجتماع رسم خريطة الأمثلة (Example Mapping) الموصوف في توثيق Cucumber عن BDD. تُبنى الخريطة على الطاولة ببطاقات ملونة: بطاقة صفراء للقصة، وبطاقة زرقاء لكل قاعدة، وبطاقات خضراء تحت كل قاعدة للأمثلة التي توضّحها، وبطاقات حمراء للأسئلة التي لا يستطيع أحد في الغرفة الإجابة عنها. وتكشف الخريطة جاهزية القصة بنظرة واحدة: كثرة البطاقات الحمراء تعني أن القصة غير جاهزة للبناء، وكثرة البطاقات الزرقاء تعني غالباً أنها كبيرة ويجب تقسيمها. وهذه خريطة القصة SHOP-31 «تطبيق رمز خصم عند إتمام الشراء».

• القصة (صفراء): SHOP-31، تطبيق رمز خصم عند إتمام الشراء.
• القاعدة 1 (زرقاء): الرمز SAVE10 يخصم ⁦10%⁩ من مجموع فرعي قدره ⁦200.00⁩ ريال فأكثر. الأمثلة (خضراء): ⁦250.00⁩ ← يدفع ⁦225.00⁩؛ ⁦200.00⁩ ← يدفع ⁦180.00⁩؛ ⁦199.99⁩ ← يُرفض الرمز ويدفع ⁦199.99⁩.
• القاعدة 2 (زرقاء): الرمز المنتهي الصلاحية يُرفض. مثال (أخضر): انتهى الرمز في ⁦31⁩ مارس ⁦2027⁩ وطُبّق في ⁦1⁩ أبريل ⁦2027⁩، فتظهر الرسالة «انتهت صلاحية هذا الرمز».
• القاعدة 3 (زرقاء): رمز واحد لكل طلب. مثال (أخضر): طُبّق SAVE10 ثم أُدخل WELCOME5؛ والنتيجة معلّقة على بطاقة حمراء.
• الأسئلة (حمراء): هل يُحسب الحد الأدنى قبل رسوم التوصيل أم بعدها؟ هل يحلّ الرمز الثاني محل الأول أم يُرفض؟ ماذا يحدث إذا حذف العميل منتجات فنزل المجموع الفرعي تحت ⁦200.00⁩ بعد تطبيق الرمز؟

جرّبها: قصة المستخدم ← سيناريوهات اختبار جرّبها: مولّد القيم الحدّية جرّبها: مولّد جداول القرار

صياغة Gherkin: أجزاء ملف الميزة

لغة Gherkin هي الصيغة النصية التي تقرؤها أدوات BDD. تعيش السيناريوهات في ملفات نصية امتدادها .feature، ويبدأ كل سطر غير فارغ بكلمة مفتاحية، باستثناء الأوصاف الحرة. وأنت تعرف كلمات الخطوات Given وWhen وThen وAnd وBut، وScenario Outline مع جدول Examples الخاص به، من درس معايير القبول. أما ملف الميزة الكامل فيضيف حولها بنية.

بعد أن أجاب مالك المنتج عن البطاقة الحمراء الأولى (الحد الأدنى يُطبَّق على المجموع الفرعي قبل رسوم التوصيل)، صاغ الفريق القاعدتين 1 و2 من القصة SHOP-31 في الملف أدناه. فصارت كل بطاقة زرقاء Rule وكل بطاقة خضراء Scenario. ويوصي مرجع Gherkin بثلاث إلى خمس خطوات لكل سيناريو؛ فإذا زادت لم يعد المثال يُقرأ مواصفةً.

• Feature: واحدة لكل ملف. اسمها والوصف الحر تحتها يبيّنان الغرض من الميزة، والوصف لا يُنفَّذ.
• Rule: تجمع السيناريوهات التي توضّح قاعدة عمل واحدة، كالبطاقة الزرقاء مع بطاقاتها الخضراء.
• Scenario أو مرادفها Example: مثال محدد واحد لسلوك واحد.
• Background: خطوات Given مشتركة بين كل سيناريوهات الملف أو القاعدة. تعمل قبل كل سيناريو، بعد أي خطافات (Hooks) من نوع Before، وهي خطافات التهيئة في Cucumber، مثل beforeEach في المشغّلات الأخرى. اجعلها قصيرة، ولا تضع فيها إلا السياق الذي يحتاجه القارئ لفهم السيناريوهات.
• جدول البيانات (Data Table): صفوف بين علامات | تحت خطوة، تُمرَّر إلى شيفرة تلك الخطوة وسيطاً واحداً. والنص متعدد الأسطر (Doc String): نص بين سطرين من """، لنص بريد إلكتروني أو حمولة JSON.
• الوسوم (Tags) مثل @smoke أو @SHOP-31 تُعلِّم ميزة أو قاعدة أو سيناريو أو جدول أمثلة لتختار ما يُشغَّل. والوسوم تُورَّث: الوسم على الميزة ينطبق على كل سيناريو فيها.
• تبدأ التعليقات بالعلامة # في أول السطر. وتحوّل ترويسة # language: في السطر الأول الكلماتِ المفتاحية إلى لغة منطوقة أخرى.

# القصة SHOP-31. القواعد متفق عليها في جلسة خريطة الأمثلة.
@checkout
Feature: رموز الخصم عند إتمام الشراء
  يستطيع العميل إدخال رمز خصم واحد لكل طلب.
  تُحسب نسبة الخصم من المجموع الفرعي قبل رسوم التوصيل.

  Background:
    Given رموز الخصم التالية موجودة:
      | code   | percent | min_subtotal | valid_until |
      | SAVE10 | 10      | 200.00       | 2027-03-31  |

  Rule: لا يُطبَّق الرمز إلا من حدّه الأدنى للمجموع الفرعي

    Scenario: مجموع فرعي عند الحد الأدنى يحصل على الخصم
      Given لدى هدى سلة مجموعها الفرعي 200.00 ريال
      When تطبّق الرمز "SAVE10"
      Then المبلغ المستحق قبل التوصيل 180.00 ريال

    Scenario: مجموع فرعي تحت الحد الأدنى مباشرة يبقى سعره
      Given لدى هدى سلة مجموعها الفرعي 199.99 ريال
      When تطبّق الرمز "SAVE10"
      Then يُرفض الرمز مع الرسالة "أكمل 200.00 ريال لاستخدام هذا الرمز"
      And المبلغ المستحق قبل التوصيل 199.99 ريال

  Rule: الرمز المنتهي الصلاحية يُرفض

    @smoke
    Scenario: رمز يُستخدم في اليوم التالي لتاريخ انتهائه
      Given اليوم هو 1 أبريل 2027
      And لدى هدى سلة مجموعها الفرعي 250.00 ريال
      When تطبّق الرمز "SAVE10"
      Then يُرفض الرمز مع الرسالة "انتهت صلاحية هذا الرمز"

الجزء 1:1@checkout
الجزء 2:2Feature: Discount codes at checkout
الجزء 3:3  A customer can enter one discount code per order.

الجزء 4:4  Background:
    Given these discount codes exist:
الجزء 5:5      | code   | percent | min_subtotal | valid_until |
      | SAVE10 | 10      | 200.00       | 2027-03-31  |

الجزء 6:6  Rule: A code applies only from its minimum subtotal

الجزء 7:7    Scenario: A subtotal at the minimum gets the discount
الجزء 8:8      Given Huda has a cart with a subtotal of 200.00 SAR
الجزء 9:9      When she applies the code "SAVE10"
الجزء 10:10      Then the amount to pay before delivery is 180.00 SAR

جرّبها: مولّد معايير القبول

السيناريو الجيد والسيناريو الضعيف

أكثر صور سوء تطبيق BDD شيوعاً ملفُ ميزة هو في حقيقته نص اختبار (Test Script): كل نقرة وحقل وعنوان URL مكتوب بصيغة Given/When/Then. هذا الأسلوب الأمري (Imperative) ينكسر مع كل إعادة تصميم، ويدفن القاعدة تحت تفاصيل الواجهة. أما الأسلوب التصريحي (Declarative) فيقول ما يحدث بلغة الأعمال ويترك الكيفية لشيفرة الأتمتة. قارن بين صيغتين للمثال نفسه.

لا شيء في الصيغة الأولى يبيّن لماذا ⁦180.00⁩ هي الإجابة الصحيحة: فالمجموع الفرعي ⁦200.00⁩ ريال، وهو الحقيقة الوحيدة التي تعتمد عليها القاعدة، مختبئ في سعر كتاب. وخطوتها الأخيرة تفحص جدولاً في قاعدة البيانات لا يراه أي صاحب مصلحة، وخطواتها تلصق عدة إجراءات معاً بحرف «و»، فلا يمكن إعادة استخدامها. أما الصيغة الثانية فيستطيع مالك المنتج قراءتها والموافقة عليها، وتبقى صالحة دون تغيير إذا أُعيد تصميم صفحة الدفع.

• سلوك واحد لكل سيناريو، وعنوان يصرّح به: «مجموع فرعي تحت الحد الأدنى مباشرة يبقى سعره»، لا «اختبار الخصم ⁦2⁩».
• خطوات تصريحية بكلمات الأعمال؛ والنقرات مكانها تعريفات الخطوات وكائنات الصفحات (Page Objects).
• البيانات التي تغيّر النتيجة فقط. كل قيمة في السيناريو يجب أن تهمّ القاعدة، ولا يُخفى شيء تعتمد عليه القاعدة.
• نتيجة يستطيع المستخدم أو صاحب المصلحة ملاحظتها في كل Then، ومحددة بما يكفي لتفشل: «يجب أن أرى ⁦180.00⁩» لا تقول أين.
• سيناريوهات مستقلة قابلة للتكرار: كل سيناريو يجهّز سياقه بنفسه، وينجح أو يفشل وحده، بأي ترتيب وفي أي يوم. فسيناريوهات القاعدة 1 لا تذكر تاريخاً، ولذلك يجب أن تثبّت أتمتتُها ساعة المتجر على تاريخ معروف، في خطاف Before مثلاً؛ وإلا بدأت تفشل في اليوم الذي تنتهي فيه صلاحية SAVE10.
• عبارة واحدة لكل فكرة في المشروع كله، مثل «المجموع الفرعي» في كل مكان بدلاً من «إجمالي السلة» في ملف و«مبلغ العربة» في آخر، حتى تعيد الخطوات استخدام التعريفات نفسها.

# أمري: نص اختبار في ثوب سيناريو
Scenario: اختبار الخصم 2
  Given أفتح "https://shop.example/login"
  And أكتب "huda@example.com" في "email" وأنقر "Sign in"
  And أنقر "Add to cart" بجانب "Desert Stars"
  And أنقر "Checkout"
  When أكتب "SAVE10" في "code" وأنقر "Apply"
  Then يجب أن أرى "180.00"
  And جدول الخصومات فيه صف لهذا الطلب

# تصريحي: سلوك واحد بلغة الأعمال
Scenario: مجموع فرعي عند الحد الأدنى يحصل على الخصم
  Given لدى هدى سلة مجموعها الفرعي 200.00 ريال
  When تطبّق الرمز "SAVE10"
  Then المبلغ المستحق قبل التوصيل 180.00 ريال

كيف ترتبط السيناريوهات بالأتمتة

يقرأ مشغّل BDD مثل Cucumber ملفات الميزات، ويبحث لكل خطوة عن تعريف خطوة (Step Definition): دالة مسجَّلة بنمط يجب أن يطابقه نص الخطوة. والنمط في الغالب تعبير Cucumber (Cucumber Expression)، تلتقط فيه معاملات مثل {int} و{float} و{word} و{string} قيماً من النص وتمرّرها إلى الدالة وسائطَ، وتصلح التعابير النمطية (Regular Expressions) أيضاً. والكلمة المفتاحية ليست جزءاً من المطابقة: خطوة Given وخطوة Then بالنص نفسه تستدعيان التعريف نفسه، فلا يمكن أن يعني النص نفسه شيئين مختلفين في موضعين.

تعريفات الخطوات شيفرة ربط (Glue Code) ويجب أن تبقى خفيفة. فهي تترجم خطوة الأعمال إلى استدعاءات لطبقة الأتمتة التي عرفتها في درسَي «نموذج كائنات الصفحات» (Page Object Model) و«معمارية أتمتة الاختبار»: عميل API يجهّز البيانات لخطوة Given، وكائن صفحة ينفّذ خطوة When كما يفعل المستخدم، وخطوة Then تقرأ النتيجة وتُجري التأكيد (Assertion) الذي يقارن النتيجة الفعلية بالمتوقعة. والقيم التي تنتجها خطوة لخطوة لاحقة، مثل السلة التي أنشأتها Given، تُحفظ في كائن سياق. وفي Cucumber للغة JavaScript هذا هو كائن World، المتاح باسم this داخل دالة الخطوة (ولذلك تُكتب دوال الخطوات بالكلمة function لا بصيغة الدالة السهمية (Arrow Function)، لأن الدالة السهمية لا تملك this خاصاً بها) والمُنشأ من جديد لكل سيناريو، وهذا ما يبقي السيناريوهات مستقلة؛ وعادةً يُنشأ فيه أيضاً عميل API وكائنات الصفحات، لتصل إليها كل خطوة.

تنتهي كل خطوة بحالة: ناجحة (passed)، أو فاشلة (failed)، أو متخطّاة (skipped، فالخطوات التي تلي خطوة فاشلة أو معلّقة أو غير معرَّفة لا تُشغَّل)، أو معلّقة (pending، تعريف لم يكتمل بعد)، أو غير معرَّفة (undefined، لا تعريف يطابقها، ويطبع Cucumber مقتطف شيفرة للبدء منه)، أو ملتبسة (ambiguous، يطابقها أكثر من تعريف). ويعرض التقرير السيناريوهات والخطوات بكلمات ملف الميزة، فتدلّ خطوة Then الفاشلة على القاعدة التي انكسرت. والوسوم تختار ما يُشغَّل، مثل npx cucumber-js --tags "@smoke and not @wip" في خط الأنابيب (Pipeline).

import { Given, When, Then } from "@cucumber/cucumber";
import assert from "node:assert/strict";

// يطابق خطوة Background؛ ويصل جدول البيانات وسيطاً أخيراً
Given("رموز الخصم التالية موجودة:", async function (table) {
  for (const row of table.hashes()) await this.api.createCode(row);
});

// يطابق: Given لدى هدى سلة مجموعها الفرعي 200.00 ريال
Given("لدى {word} سلة مجموعها الفرعي {float} ريال",
  async function (customer, subtotal) {
    this.cart = await this.api.createCart(customer, subtotal);
  });

// يطابق: When تطبّق الرمز "SAVE10"
When("تطبّق الرمز {string}", async function (code) {
  await this.checkout.open(this.cart);
  await this.checkout.applyCode(code);
});

// يطابق الخطوتين: Then المبلغ المستحق ... وAnd المبلغ المستحق ...
Then("المبلغ المستحق قبل التوصيل {float} ريال",
  async function (expected) {
    assert.equal(await this.checkout.amountBeforeDelivery(), expected);
  });

Then("يُرفض الرمز مع الرسالة {string}", async function (message) {
  assert.equal(await this.checkout.codeMessage(), message);
});

جرّبها: أداة اختبار Regex

أسئلة شائعة

المراجع

• Gherkin Reference — CucumberCucumberصياغة Gherkin للمواصفات القابلة للتنفيذ: Feature وRule وScenario، وخطوات Given/When/Then، وBackground وScenario Outline وExamples.
• Behaviour-Driven Development — CucumberCucumberالتطوير الموجّه بالسلوك (BDD) كثلاث ممارسات — الاكتشاف والصياغة والأتمتة — قائمة على أمثلة محددة يتفق عليها أهل الأعمال والفريق التقني.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.