التأكيدات في أتمتة الاختبار

لماذا يهم

لا يجد الاختبار إلا العيوب التي تبحث عنها تأكيداته. فاختبار إتمام شراء لا يتحقق إلا من «ظهور إجمالي ما» يبقى ناجحاً حين لا تُضاف ضريبة القيمة المضافة، ويُخبر التشغيلُ الناجح الفريقَ بأن الميزة تعمل. ويسمّي ISTQB النتيجة التي تفوّت عيباً موجوداً نتيجةً سلبية زائفة (False-negative result)، والتأكيدات الضعيفة تُنتج هذه النتائج بصمت.

والخطأ المعاكس مكلف أيضاً. فالتأكيدات التي تقرأ الصفحة مبكراً، أو تتحقق من تفاصيل لم يحددها أحد، تفشل دون أن يكون هناك عيب: نتائج إيجابية زائفة (False-positive results). كل إنذار كاذب يكلّف تحقيقاً، والفريق الذي يرى كثيراً منها يبدأ بإعادة تشغيل الاختبارات الفاشلة بدلاً من قراءة نتائجها. والتأكيدات الدقيقة التي تعيد المحاولة وتحمل رسائل واضحة تُبقي مجموعة الاختبارات جديرة بالثقة: فحين تفشل، تخبرك الرسالة هل تفتح تقرير عيب.

ما الذي تتحقق منه: النتيجة، وبدقة

يحتاج كل تأكيد إلى نتيجة متوقعة مصدرها المرجع (Test Oracle): المتطلب، أو معايير القبول، أو توثيق الواجهة البرمجية، أو حالة الاختبار. ولا تأخذها أبداً مما يعرضه التطبيق اليوم؛ فنسخ المخرجات الحالية إلى التأكيد يحوّل عيباً موجوداً إلى سلوك «متوقع».

التأكيد القوي يتحقق من النتيجة التي يصفها المرجع، وبالدقة التي يحددها. أما التأكيد الضعيف فيتحقق من شيء يبقى صحيحاً حتى حين تكون الميزة معطّلة: أن عنصراً موجود، أو أن قيمة غير فارغة، أو أن الاستجابة «OK». والمثال المستمر في هذا الدرس: منتجان قيمتهما ⁦150.00⁩ ريالاً مع ضريبة القيمة المضافة ⁦15%⁩ يجب أن يكون إجماليهما ⁦172.50⁩ ريالاً.

• قيم دقيقة حيث يحددها المتطلب: toHaveText('172.50 SAR') لا toBeVisible() على الإجمالي. تُقارن المبالغ والأعداد والحالات والرسائل مقارنةً تامة.
• الأنماط فقط للأجزاء المتغيرة فعلاً: رقم طلب مثل ORD-418305 يُتحقق منه بالنمط /^ORD-\d{6}$/، لا بـtoBeTruthy() ولا بالرقم الذي ظهر في تشغيل واحد.
• العدد لا «واحد على الأقل»: toHaveCount(2) لا التحقق من أن count() أكبر من صفر.
• الأثر لا مجرد غياب الخطأ: بعد الطلب تُظهر شارة السلة العدد 0؛ وإذا نصّ توثيق الواجهة البرمجية على أن إنشاء الطلب يعيد 201 مع الطلب الجديد في الجسم، فتحقّق من هذا الرمز ومن تلك القيم، لا من أي رمز من فئة 2xx.
• الغياب مع مرساة: «لا توجد رسالة خطأ» صحيح أيضاً على صفحة فارغة، فتحقّق أولاً من إشارة إيجابية ثم من الغياب.
• لا أكثر من اللازم: أصناف CSS وبنية الصفحة والطوابع الزمنية والمعرّفات المولَّدة تُفشل الاختبار عند تغييرات غير ضارة. تحقّق من سلوك واحد في كل اختبار، بعدد التأكيدات الذي يلزم لإثباته.

جرّبها: مختبِر REST API جرّبها: مختبِر JSON Path

التأكيدات الصارمة والمرنة

التأكيد الصارم (Hard Assertion) يوقف الاختبار عند أول فشل: يرمي expect خطأً، ويسجّله مشغّل الاختبارات، ولا تُنفَّذ الأسطر التي تليه أبداً. وهذا هو السلوك الافتراضي في كل أطر العمل، وهو الصحيح حين تعتمد الخطوات اللاحقة على هذا التحقق: فإذا لم تُفتح صفحة اكتمال الطلب، فإن التحقق من إجماليها لا يضيف إلا ضجيجاً.

أما التأكيد المرن (Soft Assertion) فيسجّل الفشل ويترك الاختبار يكمل؛ وفي النهاية يُعلَّم الاختبار فاشلاً مع قائمة بكل تحقق فشل. استخدمه للحقائق المستقلة عن نتيجة واحدة، مثل حقول صفحة واحدة أو استجابة واحدة، فيُظهر تشغيل واحد كل حالات عدم التطابق بدلاً من حالة واحدة في كل دورة إصلاح وإعادة تشغيل. وأبقِ الشروط المسبقة صارمة.

• JUnit 5 وما بعده: تنفّذ assertAll(...) مجموعة من التأكيدات وتبلّغ عن كل فشل فيها، وتوفّر AssertJ الصنف SoftAssertions.
• TestNG: لا يبلّغ SoftAssert إلا عند استدعاء assertAll() في النهاية؛ وإذا نسيت هذا الاستدعاء ضاعت حالات الفشل.
• pytest: عبارة assert العادية صارمة، والتحققات المرنة تأتي من إضافات (Plugins).

// Hard: the precondition. If it fails, the checks below would mean nothing.
await expect(page.getByRole('heading', { name: 'Order confirmed' })).toBeVisible();

// Soft: independent facts about the same page, all reported together.
await expect.soft(page.getByTestId('order-status')).toHaveText('Paid');
await expect.soft(page.getByTestId('order-item')).toHaveCount(2);
await expect.soft(page.getByTestId('order-total')).toHaveText('172.50 SAR');

التأكيدات التي تعيد المحاولة (Web-first)

تتغير الصفحة بعد كل إجراء: ينتهي النقر، ثم يصل الطلب إلى الخادم، وبعدها فقط يتحدّث النص. والتأكيد الذي يقرأ الصفحة مرة واحدة قد يقرؤها مبكراً. أما التأكيدات التي تعيد المحاولة، ويسمّيها توثيق Playwright التأكيدات التي تعيد المحاولة تلقائياً (Auto-retrying) أو Web-first، فتأخذ محدِّداً (Locator) بدلاً من قيمة، وتعيد التحقق حتى يتحقق الشرط أو تنتهي المهلة (⁦5⁩ ثوانٍ افتراضياً في Playwright، وهي قابلة للتعديل). ويعيد Cypress بالطريقة نفسها الاستعلام الذي يسبق .should(). أما Selenium فلا يوفّر تأكيدات تعيد المحاولة: انتظر الشرط باستخدام WebDriverWait ثم تحقّق.

الفرق في موضع await. فالسطر await expect(locator).toHaveText('Paid') يسلّم المحدِّد إلى التأكيد، فيظل يسأل الصفحة. أما expect(await locator.textContent()).toBe('Paid') فيقرأ مرة واحدة ويقارن نصاً لن يتغير أبداً، فتتوقف النتيجة على التوقيت، وهذا سبب شائع للاختبارات المتذبذبة (Flaky Tests). ودوال المطابقة (Matchers) العامة مثل toBe وtoEqual لا تعيد المحاولة من تلقاء نفسها؛ استخدمها للقيم المكتملة أصلاً، مثل جسم استجابة بعد تحليله. وللقيم الموجودة خارج الصفحة تستدعي expect.poll() دالةً مرة بعد مرة، وتطبّق دالة المطابقة على كل نتيجة جديدة.

• تعيد المحاولة في Playwright: toBeVisible وtoHaveText وtoContainText وtoHaveValue وtoHaveCount على المحدِّد، وtoHaveURL وtoHaveTitle على الصفحة.
• التحققات السلبية تعيد المحاولة أيضاً: not.toBeVisible() تنتظر اختفاء العنصر، وتنجح فوراً إن لم يظهر أصلاً، ولذلك تحتاج إلى مرساة.
• إعادة المحاولة تنتظر الإجابة الصحيحة، لكنها لا تُصلح توقعاً خاطئاً. ارفع المهلة فقط لخطوة معروفة البطء، وعلى ذلك التأكيد وحده. ويتعمّق درس الانتظار والتزامن في هذا الموضوع.

// Reads once: may compare the text from before the server answered
expect(await page.getByTestId('order-status').textContent()).toBe('Paid');

// Retries until the text is "Paid" or the timeout ends (5 s by default)
await expect(page.getByTestId('order-status')).toHaveText('Paid');

// A value outside the page: poll the API until the order is paid
await expect.poll(async () => {
  const res = await request.get('/api/orders/' + orderId);
  return (await res.json()).status;
}).toBe('PAID');

رسائل فشل تشرح نفسها

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

• فضّل دوال المطابقة التي تحمل القيم (toHaveText وtoEqual وtoHaveCount) على toBe(true) وtoBeTruthy().
• أضف رسالة مخصصة حيث لا تعرف دالة المطابقة السياق: الوسيط الثاني لـexpect في Playwright، والوسيط الأخير لـassertEquals في JUnit 5 وما بعده، والنص بعد الفاصلة في pytest: assert total == 172.5, "order total with VAT".
• اكتبها كحقيقة من منطق العمل، مثل عنوان تقرير خطأ: «حالة الطلب بعد الدفع بالبطاقة»، لا «التحقق رقم ⁦3⁩». وإذا كرّر الاختبار نفسه على بيانات مختلفة، فضمّن الحالة في الرسالة.
• في الكائنات تطبع toEqual فرقاً (Diff) بالحقول المختلفة، وتقارن toMatchObject الحقول التي تذكرها فقط، فتُبقي الطوابع الزمنية خارج المقارنة.

Weak:    expect(await status.isVisible()).toBe(true);

         Error: expect(received).toBe(expected)
         Expected: true
         Received: false

Strong:  await expect(status, 'order status after card payment').toHaveText('Paid');

         Error: order status after card payment
         Expected string: "Paid"
         Received string: "Pending"

جرّبها: مقارنة النصوص (Diff) جرّبها: مقارنة JSON

مثال تطبيقي: تقوية اختبار إتمام الشراء

المتطلب: «بعد الدفع تعرض صفحة اكتمال الطلب رقم الطلب (ORD- متبوعاً بستة أرقام)، والحالة Paid، والمنتجات المطلوبة، والإجمالي شاملاً ضريبة القيمة المضافة ⁦15%⁩. وتُفرَّغ السلة». تحتوي سلة الاختبار على منتجين قيمتهما ⁦150.00⁩ ريالاً، فالإجمالي المتوقع ⁦172.50⁩ ريالاً.

• قبل التعديل، يقرأ التحققان الأوّلان مرة واحدة ويقبلان أي شيء: إجمالي ⁦150.00⁩ ريالاً، أو رقم طلب ORD- بلا أرقام، يبقى ناجحاً. وبعده يُقارن الإجمالي الدقيق ونمط الرقم، مع إعادة المحاولة.
• عنوان «Order confirmed» تأكيد صارم: من دون صفحة اكتمال الطلب لا معنى لأي شيء آخر. والحقائق الخمس من المتطلب مرنة، فيبلّغ تشغيل واحد عن كل ما هو خاطئ منها.
• حُذف التحقق من «Error»: كان ينجح على صفحة فارغة، وبعد إثبات العنوان والقيم لا يضيف شيئاً.
• اسم الاختبار الجديد يصف السلوك، فيُقرأ التقرير كالمتطلب. ولا يُتحقق من وقت الطلب ولا من أصناف CSS، لأن المتطلب لا يذكرهما.

// Before: stays green as long as the page opens
test('place order', async ({ page }) => {
  const checkout = new CheckoutPage(page);
  await checkout.payWithTestCard();
  expect(await page.locator('.total').isVisible()).toBeTruthy();
  expect(await page.locator('.order-no').textContent()).toBeTruthy();
  await expect(page.getByText('Error')).not.toBeVisible();
});

// After: each assertion proves one part of the requirement
test('card payment confirms order with VAT and empties cart', async ({ page }) => {
  const checkout = new CheckoutPage(page);
  await checkout.payWithTestCard();
  await expect(page.getByRole('heading', { name: 'Order confirmed' })).toBeVisible();
  await expect.soft(page.getByTestId('order-number')).toHaveText(/^ORD-\d{6}$/);
  await expect.soft(page.getByTestId('order-status')).toHaveText('Paid');
  await expect.soft(page.getByTestId('order-item')).toHaveCount(2);
  await expect.soft(page.getByTestId('order-total'), 'total = 150.00 + 15% VAT')
    .toHaveText('172.50 SAR');
  await expect.soft(page.getByTestId('cart-count')).toHaveText('0');
});

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

أسئلة شائعة

المراجع

• Playwright DocumentationMicrosoft (Playwright)التوثيق الرسمي لـ Playwright، إطار الاختبار الشامل الذي يشغّل Chromium وWebKit وFirefox.
• Best Practices — PlaywrightMicrosoft (Playwright)اختبر السلوك الذي يراه المستخدم، واجعل الاختبارات معزولة، وفضّل المحدِّدات المتينة والتأكيدات التي تنتظر، واستخدم التتبّع لتصحيح الأخطاء.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Cypress DocumentationCypress.ioالتوثيق الرسمي لاختبار الويب الشامل واختبار المكونات في المتصفح باستخدام Cypress.