كيفية استخدام Cucumber لاختبار السلوك التوافقي (BDD)

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

ما هو Cucumber و BDD؟

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

يركز BDD على الإجابة عن سؤال واحد: "ماذا يجب أن يفعله النظام؟" بدلاً من "كيف يجب أن نختبره؟" والنتيجة هي لغة مشتركة تزيل سوء الفهم وتنشئ اختبارات تعمل كمواصفات وتحقق قابل للتنفيذ.

يقرأ Cucumber ملفات .feature التي تحتوي على سيناريوهات مكتوبة بلغة Gherkin وينفذها مقابل تعريفات الخطوات — التعليمات البرمجية التي تقوم بالأتمتة الفعلية. وهذا الفصل يعني أن أصحاب المصلحة في الأعمال يمكنهم مراجعة سيناريوهات الاختبار دون قراءة التعليمات البرمجية، بينما يقوم المطورون بتنفيذ التفاصيل التقنية بشكل منفصل.

تثبيت Cucumber لـ JavaScript

يستغرق إعداد Cucumber في مشروع Node.js بضعة أوامر فقط:

المتطلبات الأساسية:

• Node js
• NPM
• مشروع API يحتوي على ميزة تسجيل دخول سنقوم باختبارها (سيغطي هذا البرنامج التعليمي فقط تثبيت Cucumber واختبارات Gherkin).

# أنشئ دليل مشروع جديد
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo

# تهيئة npm
npm init -y

# تثبيت Cucumber وتبعات الاختبار
npm install --save-dev @cucumber/cucumber chai axios

يجب أن يتضمن ملف package.json الخاص بك سكربت اختبار:

{
  "scripts": {
    "test": "cucumber-js"
  }
}

أنشئ هذا الهيكل الدليلي:

project/
├── features/
│   └── user-management.feature
├── step-definitions/
│   └── user-steps.js
├── package.json
└── cucumber.json

دليل عملي: كتابة أول اختبار BDD لك

دعنا نبني اختبارًا لواجهة برمجة تطبيقات إدارة المستخدم لإظهار كيفية استخدام Cucumber لاختبار BDD عمليًا.

الخطوة 1: كتابة ملف الميزة (Feature File)

أنشئ features/user-management.feature:

Feature: واجهة برمجة تطبيقات إدارة المستخدم
  بصفتي عميل API
  أريد إدارة المستخدمين
  حتى أتمكن من دمج وظائف المستخدم في تطبيقي

  Scenario: إنشاء مستخدم جديد بنجاح
    Given لدي حمولة مستخدم صالحة
    When أرسل طلب POST إلى "/api/users"
    Then يجب أن تكون حالة الاستجابة 201
    And يجب أن تحتوي الاستجابة على معرف مستخدم

  Scenario: محاولة إنشاء مستخدم ببريد إلكتروني غير صالح
    Given لدي حمولة مستخدم ببريد إلكتروني غير صالح
    When أرسل طلب POST إلى "/api/users"
    Then يجب أن تكون حالة الاستجابة 400
    And يجب أن تحتوي الاستجابة على "تنسيق بريد إلكتروني غير صالح"

الخطوة 2: تنفيذ تعريفات الخطوات (Step Definitions)

أنشئ step-definitions/user-steps.js:

const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');

let requestPayload;
let response;

Given('لدي حمولة مستخدم صالحة', function() {
  requestPayload = {
    name: 'Test User',
    email: 'test@example.com',
    password: 'ValidPass123'
  };
});

Given('لدي حمولة مستخدم ببريد إلكتروني غير صالح', function() {
  requestPayload = {
    name: 'Test User',
    email: 'invalid-email',
    password: 'ValidPass123'
  };
});

When('أرسل طلب POST إلى {string}', async function(endpoint) {
  try {
    response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
  } catch (error) {
    response = error.response;
  }
});

Then('يجب أن تكون حالة الاستجابة {int}', function(statusCode) {
  expect(response.status).to.equal(statusCode);
});

Then('يجب أن تحتوي الاستجابة على معرف مستخدم', function() {
  expect(response.data).to.have.property('userId');
  expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});

Then('يجب أن تحتوي الاستجابة على {string}', function(message) {
  expect(response.data.message).to.include(message);
});

الخطوة 3: تعديل ملف Cucumber.json

أنشئ ملف "cucumber.json" في الدليل الجذر لمشروعك وأضف التعليمات البرمجية التالية:

{
    "default": {
        "formatOptions": {
            "snippetInterface": "synchronous"
        }
    }
}

الخطوة 4: تشغيل الاختبارات

نفّذ اختباراتك باستخدام:

npm test

سيقوم Cucumber بإخراج نتائج مفصلة توضح الخطوات التي نجحت، أو غير المعرفة، أو فشلت.

قواعد كتابة سيناريوهات BDD جيدة

يتطلب تعلم كيفية استخدام Cucumber لاختبار BDD بفعالية اتباع هذه القواعد المجربة:

1. بنية Given-When-Then

يجب أن يحتوي كل سيناريو على هذه الأجزاء الثلاثة بالترتيب:

• Given (بالنظر إلى): يحدد الشروط المسبقة
• When (عندما): يصف الإجراء
• Then (إذًا): يتحقق من النتيجة

2. اكتب بشكل إعلاني، وليس بشكل أمري

سيء:

Given أفتح المتصفح
And أنتقل إلى "/login"
And أكتب "test@example.com" في حقل البريد الإلكتروني
And أكتب "password" في حقل كلمة المرور
And أنقر على زر تسجيل الدخول

جيد:

Given أنا في صفحة تسجيل الدخول
When أقوم بتسجيل الدخول ببيانات اعتماد صحيحة
Then يجب أن أرى لوحة التحكم

ركز على ما تختبره، وليس على كيفية قيامك بذلك.

3. سيناريو واحد، غرض واحد

يجب أن يختبر كل سيناريو سلوكًا واحدًا. السيناريوهات المجمعة تخفي الأخطاء وتجعل تصحيح الأخطاء صعبًا.

4. استخدم لغة الأعمال

اكتب سيناريوهات يمكن لأصحاب المصلحة في الأعمال فهمها. تجنب المصطلحات التقنية وتفاصيل التنفيذ.

5. اجعل السيناريوهات مستقلة

يجب ألا تعتمد السيناريوهات على بعضها البعض. يجب أن يقوم كل سيناريو بإعداد بياناته الخاصة وتنظيفها بعد ذلك.

ميزات Cucumber المتقدمة: جداول البيانات ومخططات السيناريوهات

جداول البيانات للمدخلات المعقدة

عندما تحتاج إلى الاختبار بنقاط بيانات متعددة، استخدم الجداول:

Scenario: إنشاء مستخدمين بأدوار مختلفة
  Given لدي بيانات المستخدم التالية:
    | name     | email             | role    |
    | أليس     | alice@example.com | مسؤول   |
    | بوب      | bob@example.com   | مستخدم  |
  When أرسل طلب POST إلى "/api/users"
  Then يجب إنشاء جميع المستخدمين بنجاح

تعريف الخطوة:

Given('لدي بيانات المستخدم التالية:', function(dataTable) {
  requestPayload = dataTable.hashes();
});

مخططات السيناريو للاختبارات المعتمدة على البيانات

عندما تريد تشغيل نفس السيناريو ببيانات مختلفة، استخدم المخططات:

Scenario Outline: تسجيل الدخول ببيانات اعتماد متنوعة
  Given أنا في صفحة تسجيل الدخول
  When أدخل "" و ""
  Then يجب أن أرى ""

  Examples:
    | email             | password   | result          |
    | test@example.com  | validPass  | لوحة التحكم      |
    | test@example.com  | wrongPass  | كلمة مرور غير صالحة |
    | invalid@email.com | validPass  | بريد إلكتروني غير صالح |

ينشئ هذا ثلاثة سيناريوهات اختبار منفصلة تلقائيًا.

تنظيم الاختبارات باستخدام العلامات

تساعدك العلامات على تصنيف وتصفية السيناريوهات:

@smoke @regression
Scenario: تسجيل دخول المستخدم
  Given أنا في صفحة تسجيل الدخول
  When أقوم بتسجيل الدخول ببيانات اعتماد صحيحة
  Then يجب أن أرى لوحة التحكم

@api @critical
Scenario: فحص صحة API
  Given API يعمل
  When أطلب "/health"
  Then يجب أن تكون حالة الاستجابة 200

تشغيل علامات محددة فقط:

npm test -- --tags "@smoke"

كيف يساعد Apidog في اختبار API في سير عمل BDD

بينما يتفوق Cucumber في تحديد السلوك، يقوم Apidog بأتمتة المهام الشاقة لإنشاء واجهة برمجة التطبيقات وتنفيذها، مما يجعل Cucumber لاختبار BDD أكثر كفاءة بكثير.

توليد حالات اختبار API مدعومة بالذكاء الاصطناعي

بدلاً من كتابة تعريفات الخطوات يدويًا لمكالمات API، يقوم Apidog بتوليدها من مواصفات OpenAPI الخاصة بك باستخدام الذكاء الاصطناعي:

# مواصفات API الخاصة بك
paths:
  /api/users:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                name: string
                email: string
      responses:
        '201':
          description: تم إنشاء المستخدم

يقوم Apidog تلقائيًا بإنشاء سيناريوهات جاهزة للاختبار:

• اختبار إيجابي: حمولة صالحة ← حالة 201
• اختبار سلبي: بريد إلكتروني غير صالح ← حالة 400
• اختبار حدودي: حقل مطلوب مفقود ← حالة 400

الأسئلة المتكررة

س1: هل أحتاج إلى معرفة البرمجة لكتابة اختبارات Cucumber؟

ج: لا تتطلب كتابة سيناريوهات Gherkin أي ترميز — فقط تفكيرًا واضحًا حول السلوك. ومع ذلك، يتطلب تنفيذ تعريفات الخطوات معرفة بلغة JavaScript (أو لغة أخرى). تقلل أدوات مثل Apidog هذا العبء عن طريق توليد تعليمات تعريف الخطوات تلقائيًا.

س2: كيف يختلف Cucumber عن أطر عمل الاختبار التقليدية؟

ج: تركز أطر العمل التقليدية (Jest, Mocha) على التنفيذ التقني. يركز Cucumber على سلوك العمل. يمكن لنفس سيناريو Cucumber أن يقود اختبارات واجهة المستخدم للويب (Selenium)، أو اختبارات API (Axios)، أو اختبارات الهاتف المحمول (Appium) دون تغيير نص Gherkin.

س3: هل يمكن لـ Cucumber أن يحل محل أدوات اختبار API؟

ج: يوفر Cucumber هيكل الاختبار، ولكنك لا تزال بحاجة إلى أدوات لتنفيذ مكالمات API (Axios, Supertest) والتحقق من الاستجابات. يكمل Apidog Cucumber من خلال التعامل مع طبقة تنفيذ API بينما يدير Cucumber سير عمل BDD.

س4: ما الذي يجعل سيناريو Cucumber جيدًا؟

ج: السيناريوهات الجيدة تكون مستقلة، تستخدم لغة العمل، تتبع بنية Given-When-Then، وتختبر سلوكًا واحدًا لكل منها. يجب أن تكون قابلة للقراءة من قبل أصحاب المصلحة غير التقنيين وتركز على ما يفعله النظام، وليس كيف يفعله.

س5: كيف يتعامل Apidog مع المصادقة في اختبارات BDD؟

ج: يدير Apidog رموز المصادقة تلقائيًا. يمكنك تحديد خطوات "Given I am authenticated" (بالنظر إلى أنني مصادق) التي تستخدم إدارة بيانات الاعتماد في Apidog لاسترداد رموز صالحة، مما يلغي التعامل اليدوي مع الرموز في تعريفات الخطوات الخاصة بك.

الخاتمة

يؤدي استخدام Cucumber لاختبار BDD إلى تحويل عملية التطوير بشكل فعال من خلال خلق فهم مشترك بين الفرق التقنية والتجارية. تفرض بناء جملة Gherkin الوضوح، بينما يحافظ الفصل بين السيناريوهات وتعريفات الخطوات على سهولة صيانة الاختبارات مع تطور تطبيقك.

تأتي القوة الحقيقية من دمج Cucumber مع أدوات الأتمتة الحديثة. يلغي Apidog العمل اليدوي الشاق لكتابة كود اختبار API، مما يتيح لك التركيز على تحديد سلوكيات ذات مغزى بينما يتولى هو التنفيذ. يوفر هذا المزيج أفضل ما في العالمين: مواصفات قابلة للقراءة البشرية تعمل كوثائق حية، واختبارات آلية قوية تعمل باستمرار.

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