بيانات الاختبار والتجهيزات والخطافات

لماذا يهم

كثير من حزم الاختبارات المؤتمتة غير الموثوقة تفشل بسبب الحالة لا بسبب المنتج. اختبار ينجح منفرداً ويفشل في التشغيل الكامل لأن اختباراً سابقاً غيّر الحساب المشترك؛ وتشغيل يفشل يوم الاثنين لأن القسيمة التي يعتمد عليها الاختبار انتهت صلاحيتها؛ وطلبات متبقية من آلاف التشغيلات تُبطئ صفحة قائمة حتى تتجاوز اختباراتها المهلة. فطريقة الإعداد والتنظيف هي ما يقرر هل تعني النتيجة الحمراء عيباً أم مجرد ضجيج، والضجيج يعلّم الفريق تجاهل النتائج الحمراء.

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

أين تعيش بيانات الاختبار في الاختبار المؤتمت

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

تنطبق قاعدتان أينما كانت البيانات. الاختبار يملك البيانات التي يغيّرها: فلا يُشارَك إلا ما هو للقراءة فقط، مثل قائمة الدول أو كتالوج منتجات لا يعدّله أي اختبار. والحقل الذي يجب أن يكون فريداً يأخذ قيمة فريدة في كل تشغيل، مثل sara+${runId}@example.com، حتى لا يفشل تشغيل ثانٍ أو عامل (Worker) موازٍ برسالة «موجود مسبقاً» (already exists).

أما البيانات نفسها فيمكن أن تعيش في أربعة أماكن؛ اختر بحسب ما يحتاج قارئ الاختبار أن يراه.

• داخل الاختبار نفسه: القيمة أو القيمتان اللتان تشرحان الاختبار، مثل quantity: 0 في اختبار عنوانه «يرفض الكمية صفراً». أبقِ القيمة المهمة ظاهرة بجوار التأكيد.
• دالة بانية أو دالة مصنع (Factory): makeCustomer({ country: "JO" }) تُعيد سجلاً صالحاً كاملاً بقيم افتراضية معقولة، ويغيّر الاختبار الحقل الذي يخصّه فقط. وإذا ظهر حقل إلزامي جديد، عدّلت المصنع مرة واحدة.
• ملف بيانات: جدول CSV أو JSON في المستودع بجوار الاختبارات، حين تشترك حالات كثيرة في جسم اختبار واحد. ويُراجَع ويُدار إصداره كالشيفرة تماماً.
• حالة تُنشأ قبل الاختبار: سجلات يجب أن تكون موجودة، تُنشأ عبر الواجهة البرمجية (API) أو سكربت زرع (Seed) لا بالنقر عبر الشاشات، لأن النقر أبطأ ويفشل لأسباب لا تخص الاختبار.

جرّبها: مصنع بيانات الاختبار جرّبها: مولّد UUID

الخطافات: شيفرة يستدعيها المشغّل قبل الاختبارات وبعدها

توفر معظم المشغّلات أربعة خطافات: beforeAll يعمل مرة واحدة قبل أول اختبار في الملف أو المجموعة، وbeforeEach قبل كل اختبار، وafterEach بعد كل اختبار، وafterAll مرة واحدة بعد آخر اختبار. يستخدم Jest وVitest هذه الأسماء بعينها؛ ويكتبها Playwright Test بصيغة test.beforeEach وما يشبهها؛ ويستخدم JUnit 5 التعليقات التوضيحية (Annotations) @BeforeAll و@BeforeEach و@AfterEach و@AfterAll. ويدعم pytest دوال إعداد وتفكيك بسيطة أيضاً، لكن أداته المعتادة هي التجهيزة، ونشرحها في القسم التالي.

الترتيب لكل اختبار هو: خطافات beforeEach، ثم جسم الاختبار، ثم خطافات afterEach. وفي المجموعات المتداخلة يعمل beforeEach الخاص بالمجموعة الخارجية قبل الخاص بالداخلية. والخاصية المهمة أن الخطافات اللاحقة تعمل حتى عندما يفشل الاختبار. فالتأكيد الفاشل يوقف جسم الاختبار عند ذلك السطر، لذا لا يعمل أبداً التنظيف المكتوب في آخر أسطر الجسم، بينما يعمل التنظيف الموضوع في afterEach.

استخدم beforeEach للحالة التي تغيّرها الاختبارات، ليبدأ كل اختبار من جديد. واستخدم beforeAll فقط للإعداد المكلف الذي تقرؤه الاختبارات ولا تغيّره أبداً، مثل تشغيل خادم بديل (Stub)؛ فالبيانات القابلة للتغيير التي تُنشأ مرة وتغيّرها عدة اختبارات تجعل النتيجة معتمدة على ترتيب تشغيل الاختبارات. وفي Playwright Test يعمل beforeAll مرة لكل عملية عامل (Worker Process)، ويعمل مجدداً في العامل الجديد الذي يحل محل سابقه بعد فشل اختبار، لذا يجب أن يكون آمناً إذا تكرر تشغيله.

import { test, expect } from '@playwright/test';

test.describe('saved addresses', () => {
  const created: string[] = [];              // ids of addresses these tests created

  test.beforeEach(async ({ page }) => {
    await page.goto('/account/addresses');   // every test starts on the same page
  });

  test.afterEach(async ({ request }) => {      // request: an HTTP client for the API
    for (const id of created) {              // runs even when the test failed
      await request.delete(`/api/addresses/${id}`);
    }
    created.length = 0;
  });

  test('lists an address added through the API', async ({ page, request }) => {
    const res = await request.post('/api/addresses', { data: { city: 'Riyadh' } });
    created.push((await res.json()).id);
    await page.reload();
    await expect(page.getByText('Riyadh')).toBeVisible();
  });
});

التجهيزات: إعداد يطلبه الاختبار باسمه

تجمع التجهيزة ثلاثة أشياء: الإعداد (Setup)، والقيمة التي يتسلّمها الاختبار، والتفكيك (Teardown). ويطلب الاختبار التجهيزة باسمها بدلاً من أن يستدعي شيفرة الإعداد بنفسه. في Playwright Test تُعدّ page (صفحة في المتصفح) وrequest (عميل HTTP لاستدعاء الواجهة البرمجية مباشرةً) تجهيزات مدمجة، وتضيف تجهيزاتك بـtest.extend: الشيفرة قبل await use(value) إعداد، ويعمل الاختبار أثناء use، والشيفرة بعدها تفكيك يعمل سواء نجح الاختبار أم فشل. وفي pytest التجهيزة دالة موسومة بـ@pytest.fixture يطلبها الاختبار بذكر اسمها معاملاً له؛ وهي تسلّم القيمة بـyield، والشيفرة بعد yield هي التفكيك.

مقارنةً بالخطافات، تعمل التجهيزات عند الطلب: لا يدفع كلفة إنشاء عميل إلا الاختبار الذي يطلب customer. وهي قابلة للتركيب: تجهيزة order يمكن أن تطلب تجهيزة customer، ويجري التفكيك بالترتيب المعاكس، فيُحذف الطلب قبل عميله. ولها نطاق (Scope): لكل اختبار افتراضياً، أو مشتركة على نطاق أوسع، لكل عامل في Playwright أو لكل وحدة برمجية (Module) أو جلسة في pytest، للأشياء المكلفة التي تقرؤها الاختبارات فقط. وفي Playwright Test تُعَدّ التجهيزة افتراضياً عند الحاجة (Lazily)، قبيل أول خطاف أو اختبار يطلبها: فـpage التي يستخدمها خطاف beforeEach تكون جاهزة قبل تشغيل ذلك الخطاف، أما customer الذي لا يطلبه إلا جسم الاختبار فيُنشأ بعد خطافات beforeEach. وتُفكَّك التجهيزات ذات نطاق الاختبار بعد خطافات afterEach.

أبقِ القيم المهمة ظاهرة. يجب أن تُخفي التجهيزة كيف يُنشأ العميل، لا نوع العميل الذي يحتاجه الاختبار؛ فإذا اعتمد الاختبار على تفصيل مثل دولة العميل، فمرّره صراحةً أو أنشئ تجهيزة منفصلة باسم واضح.

// fixtures.ts
import { test as base, expect } from '@playwright/test';
import { randomUUID } from 'node:crypto';

type Customer = { id: string; email: string };

export const test = base.extend<{ customer: Customer }>({
  customer: async ({ request }, use) => {
    // setup: a fresh customer for this test only
    const email = `sara+${randomUUID()}@example.com`;
    const res = await request.post('/api/customers', { data: { email } });
    const customer: Customer = await res.json();

    await use(customer);                     // the test runs here

    // teardown: runs after the test, passed or failed
    await request.delete(`/api/customers/${customer.id}`);
  },
});
export { expect };

// orders.spec.ts
import { test, expect } from './fixtures';

test('a new customer has no orders', async ({ request, customer }) => {
  const res = await request.get(`/api/customers/${customer.id}/orders`);
  expect(await res.json()).toEqual([]);
});

جرّبها: مولّد مستخدمين وهميين

التنظيف: اترك البيئة كما وجدتها

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

• ضع التنظيف (Cleanup) في خطاف لاحق أو في تفكيك التجهيزة، ولا تضعه أبداً في نهاية جسم الاختبار وحدها.
• احذف بالضبط ما أنشأه الاختبار، بالمعرّف. ولا تنظّف أبداً باستعلام واسع مثل «احذف كل عميل ينتهي بريده بـexample.com»: ففي البيئة المشتركة يزيل ذلك بيانات الآخرين وبيانات التشغيلات المتوازية.
• افصل خطوات الإعداد، حتى لا تؤدي خطوة فاشلة إلى تخطي تفكيك الخطوات التي سبقتها؛ ولهذا السبب توصي وثائق pytest بإجراء واحد يغيّر الحالة في كل تجهيزة.
• اجعل التفكيك متسامحاً مع سجل محذوف أصلاً، كأن يكون الاختبار قد حذفه بنفسه، لكن أبلغ عن أي فشل آخر في التنظيف بدلاً من إخفائه.
• فضّل البيانات التي تزول وحدها حيث يسمح الإعداد بذلك: معاملة قاعدة بيانات (Transaction) يُتراجع عنها (Rollback) بعد كل اختبار، في اختبارات التكامل التي تشارك الشيفرةَ المختبَرة اتصالَ قاعدة البيانات نفسه؛ أو حاوية جديدة أو بيئة يُعاد ضبطها في كل تشغيل؛ أو مستأجر (Tenant) منفصل لكل تشغيل.
• ميّز البيانات المنشأة ببادئة التشغيل، مثل AT-20261002-0412-، لتتمكن مهمة مجدولة من العثور على ما تركته التشغيلات المتعطلة وإزالته.

مثال تطبيقي: اختبار واحد وجدول من رموز الخصم

المتطلب: «الرمز SAVE10 يمنح خصم ⁦10%⁩ على الطلبات بقيمة ⁦200.00⁩ ريال فأكثر، ويُرفض على ما دونها برسالة الحد الأدنى للطلب. والرموز لا تميّز بين الأحرف الكبيرة والصغيرة. والرمز المنتهي أو غير المعروف يُبقي الإجمالي كما هو ويعرض خطأ». كتابة ستة اختبارات شبه متطابقة تنسخ الخطوات نفسها ست مرات. أما الاختبار المعتمد على البيانات فيُبقي جسم اختبار واحداً وينقل الحالات إلى جدول؛ ويصف مسرد ISTQB الاختبار المعتمد على البيانات بأنه تقنية لكتابة السكربتات تحفظ فيها ملفاتُ البيانات بياناتِ الاختبار والنتائجَ المتوقعة.

كل المشغّلات الرئيسية تدعم ذلك. في Jest وVitest ينشئ test.each(rows)("$case", fn) اختباراً لكل صف ويضع قيمة case في عنوانه. وفي pytest يفعل @pytest.mark.parametrize("row", rows) الشيء نفسه، ويسمّي pytest.param(row, id=...) كل حالة. وفي JUnit 5 يقرأ @ParameterizedTest مع @CsvFileSource(resources = "/discount-cases.csv", numLinesToSkip = 1) الصفوف من ملف CSV ويتخطى سطر العناوين. أما Playwright Test فلا يوفر test.each؛ وتنشئ وثائقه test() لكل صف داخل حلقة، ويجب أن يكون كل عنوان فريداً.

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

• أعطِ كل صف عموداً للاسم. عندها يقول التقرير «فشلت حالة expired code» بدلاً من «فشل الصف ⁦5⁩».
• اكتب القيم كما يعرضها النظام تماماً: 200.00 لا 200. وفي CSV ينبغي وضع القيمة التي تحوي فاصلة أو علامة اقتباس مزدوجة أو فاصل أسطر بين علامتي اقتباس مزدوجتين، وتُكتب علامة الاقتباس المزدوجة داخلها مرتين (RFC 4180).
• المأزق الأول، الجدول العملاق: ملف من ⁦200⁩ صف بأعمدة لكل ميزة لا يمكن مراجعته، وكل تغيير يمسّه. اجعل لكل قاعدة جدولها، صغيراً بما يكفي ليُقرأ في دقيقة، واختر الصفوف بتقنيات تصميم الاختبار مثل تحليل القيم الحدّية بدلاً من تكديسها.
• المأزق الثاني، منطق الاختبار المخبأ في البيانات: أعمدة مثل click_apply_twice أو skip_login تحوّل الجدول إلى برنامج لا يختبره أحد. فإذا احتاجت الصفوف خطوات مختلفة، فهي اختبارات مختلفة. والأمر نفسه للنتائج المتوقعة التي يحسبها الاختبار بمعادلة المنتج نفسها: عندها يختبئ عيب المعادلة في الطرفين.

data/discount-cases.csv
case,code,cart_total,expected_total,error
valid code,SAVE10,250.00,225.00,
lower-case code,save10,200.00,180.00,
minimum order exactly,SAVE10,200.00,180.00,
just below minimum,SAVE10,199.99,199.99,MIN_ORDER
expired code,OLD5,200.00,200.00,EXPIRED
unknown code,NOPE10,200.00,200.00,NOT_FOUND

test_discounts.py  (pytest: one test body, six reported tests)
import csv
from decimal import Decimal
import pytest

def load_cases(path):
    with open(path, newline="", encoding="utf-8") as f:
        return [pytest.param(row, id=row["case"]) for row in csv.DictReader(f)]

@pytest.mark.parametrize("row", load_cases("data/discount-cases.csv"))
def test_discount_code(cart, row):           # cart: a fixture, fresh per test
    cart.set_total(Decimal(row["cart_total"]))
    result = cart.apply_code(row["code"])
    assert result.total == Decimal(row["expected_total"])
    assert result.error == (row["error"] or None)

جرّبها: مولّد مجموعات بيانات CSV جرّبها: محوّل CSV إلى JSON

أسئلة شائعة

المراجع

• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Playwright DocumentationMicrosoft (Playwright)التوثيق الرسمي لـ Playwright، إطار الاختبار الشامل الذي يشغّل Chromium وWebKit وFirefox.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesIETF · 2005قواعد CSV الشائعة: الفاصلة كفاصل، ونهايات الأسطر CRLF، وتحويط الحقول التي تحتوي فواصل أو علامات اقتباس أو أسطر جديدة.