الاختبارات الآلية تقلل الخوف من التغيير عندما تتحقق من سلوك مهم بصورة متكررة. لكنها قد تصبح عبئًا إذا كانت هشة أو بطيئة أو مرتبطة بتفاصيل التنفيذ. الهدف ليس أكبر عدد من الاختبارات، بل مجموعة تكشف الأخطاء المهمة بسرعة وتوضح سبب الفشل.
ما ستخرج به من المقال
- اختبار القواعد الصغيرة في طبقة مناسبة.
- استخدام التكامل عند تفاعل المكونات.
- اختبار مسارات المستخدم الحرجة عبر المتصفح.
اختبارات الوحدة
تختبر وحدة صغيرة مثل دالة حساب خصم أو تحويل حالة وتكون عادةً سريعة. فائدتها تحديد موضع الخطأ بسرعة وتغطية الحالات الطرفية. اختبر النتيجة والسلوك المتعاقد عليه لا تفاصيل داخلية لا تهم المستهلك. إذا احتاج كل اختبار mocks كثيرة فقد تكون حدود المكونات غير واضحة أو أن الدالة تؤدي مسؤوليات كثيرة.
اختبارات التكامل
تتحقق من تفاعل أجزاء مثل route مع قاعدة بيانات اختبار أو خدمة تستخدم adapter. تلتقط أخطاء لا تظهر في mocks، مثل اختلاف SQL الفعلي أو نسيان transaction. جهّز بيانات الاختبار بصورة معزولة وقابلة للتكرار ونظف الحالة بعده؛ لا تعتمد على حسابات مشتركة أو خدمة إنتاج حقيقية تتغير بياناتها بمرور الوقت.
اختبارات المتصفح E2E
تحاكي رحلة مستخدم من الواجهة إلى الخلفية عبر أجزاء النظام، مثل تسجيل الدخول وإكمال طلب. لكنها أبطأ وأكثر حساسية للوقت والشبكة؛ لا تجعلها تغطي وحدها كل تفاصيل الوظائف. اجعلها تنتظر حالة ذات معنى بدل sleep ثابت، واستخدم selectors مستقرة مثل role وlabel، واختبر النتائج المرئية والرسائل المهمة بدل أسماء CSS داخلية تتغير باستمرار.
التغطية والفشل القابل للتشخيص
نسبة Coverage تساعد في كشف مناطق ربما لا توجد لها اختبارات، لكنها لا تقيس جودة assertions. أضف اختبارًا يعيد إنتاج كل bug مهم، وغطّ النجاح والفشل والحدود خصوصًا في الصلاحيات والبيانات. استخدم أسماء سيناريو ورسائل مفيدة ومرفقات عند فشل المتصفح، وراقب زمن suite والفشل المتقطع. لا تعالج flakiness بإعادة التشغيل بلا نهاية؛ ابحث عن مصدر عدم الحتمية.
اختبار بحث باستخدام Playwright
import { test, expect } from "@playwright/test";
test("user can search articles", async ({ page }) => {
await page.goto("/");
await page.getByRole("searchbox").fill("PostgreSQL");
await expect(
page.getByRole("link", { name: /postgresql/i }).first()
).toBeVisible();
});
اختبر السلوك الذي يهم المستخدم
الاختبار المفيد يبدأ بسؤال واضح: ما السلوك الذي يجب أن يستمر صحيحًا عند تغير الكود؟ اختبار وحدة لدالة حساب إجمالي قد يكون سريعًا ومحددًا، واختبار تكامل يثبت أن repository وقاعدة البيانات يتعاملان بصورة صحيحة، واختبار متصفح يثبت أن المستخدم يستطيع البحث وإكمال المهمة عبر الواجهة. لكل طبقة مستوى مختلف من السرعة والثقة والتكلفة.
لا تختبر التفاصيل الداخلية فقط، وإلا قد تفشل الاختبارات عند إعادة هيكلة لا تغير السلوك. وفي الوقت نفسه، لا تضع كل الحالات في اختبارات متصفح بطيئة. توزيع الاختبارات على مستويات متعددة يجعل الفشل أدق تشخيصًا ويقلل زمن التغذية الراجعة للفريق.
دراسة حالة مفصلة: من العرض إلى السبب الجذري
الحالة العملية هنا هي: ينجح اختبار متصفح منفردًا لكنه يفشل داخل CI بسبب بيانات مشتركة أو انتظار زمني هش. لا يكفي أن نصلح العَرَض الظاهر؛ ينبغي رسم مسار البيانات أو الطلب من بدايته حتى النتيجة، ومعرفة أين نشأ الاختلاف. ابدأ بتسجيل ما حدث، وما المتوقع أن يحدث، والخطوة التي يمكن إثباتها بالقياس أو السجل أو الاختبار. بعد ذلك غيّر عاملًا واحدًا واضحًا، ثم أعد السيناريو نفسه للتحقق من أن السبب الجذري عولج. إذا تغيرت عدة مكونات دفعة واحدة، فسيصعب معرفة أيها أحدث الفرق.
اربط نتيجة الحالة بمبدأ المقال: اختبارات الوحدة واختبارات التكامل. هذان المفهومان يحددان ما الذي يجب فحصه أولًا وما الذي يمكن تأجيله. سجّل أيضًا الحالات التي لم تختبرها، حتى لا يتحول نجاح سيناريو واحد إلى ادعاء بأن النظام كله خالٍ من المشكلة.
اجعل الاختبارات قابلة للتكرار
الاختبار الذي يعتمد على وقت حقيقي أو خدمة خارجية متقلبة أو ترتيب غير مضمون قد يفشل دون أن يتغير المنتج. استخدم fixtures وبيانات اختبار واضحة، واعزل الاعتماديات عندما يكون هذا العزل لا يخفي السلوك المراد اختباره. إذا احتاج الاختبار ساعة نظام أو مصدر عشوائي، اجعل هذه التبعيات قابلة للضبط ضمن الاختبار.
لا تشارك حالة عالمية بين الاختبارات على نحو يسبب اعتمادًا على ترتيب تشغيلها. نظّف البيانات بعد كل اختبار أو استخدم قاعدة مؤقتة معزولة. عند الاختبارات المتوازية، امنح كل عامل مجموعة بيانات أو مساحة مستقلة عند الحاجة، وتجنب استخدام حساب واحد قابل للتعديل من اختبارات متزامنة.
من المثال إلى التنفيذ في مشروع حقيقي
ابدأ من المثال البرمجي المعروض في المقال: «اختبار بحث باستخدام Playwright». لا تنقله حرفيًا إلى الإنتاج قبل أن تحدد مدخلاته ومخرجاته وافتراضاته. اسأل ما الذي يحدث عند غياب قيمة، أو وصول بيانات غير متوقعة، أو تكرار الطلب، أو تأخر الاعتماد الخارجي. بعد ذلك نفّذ نسخة صغيرة داخل فرع مستقل وأضف اختبارًا للحالة الأساسية وآخر لحالة فشل.
استخدم هذه الخطوات كبداية: ابدأ بسلوك مهم أو bug متكرر. ثم اختر طبقة الاختبار حسب موضع القاعدة. ثم اجعل البيانات والبيئة قابلة للتكرار.. اجعل كل خطوة قابلة للمراجعة، ولا تجمع إعدادات المشروع الحقيقية والأسرار داخل مثال تعليمي. إذا اختلفت بيئتك عن المثال، وثّق الاختلاف وعدّل التنفيذ بناءً على التوثيق الرسمي بدل نسخ الحل دون فهم.
اقرأ فشل الاختبار كإشارة
عندما يفشل اختبار، احتفظ بالرسالة والسياق وصورة المتصفح أو trace عند ملاءمتها. في اختبارات Playwright، استخدم locators دلالية مثل الدور والاسم المرئي قدر الإمكان بدل selectors هشة مرتبطة بتركيب DOM الداخلي. انتظر شرطًا محددًا بدل إضافة sleep ثابت، لأن التأخير قد يفشل على جهاز أبطأ ويبطئ جميع التشغيلات.
ميز بين فشل المنتج وفشل الاختبار وفشل البيئة. لا تضف retry لكل شيء حتى يخفي الفشل المتقطع؛ سجل معدل flaky tests وأصلح السبب. إذا كان الاختبار يعتمد على شبكة حقيقية، فحدد ما الذي يختبره ذلك الاعتماد ولماذا لا يمكن عزله دون فقدان قيمة الاختبار.
أسلوب تشخيص منهجي عند الفشل
عندما لا يعمل الحل، لا تبدأ بإضافة شرط آخر قبل تحديد دليل الفشل. دوّن المدخل، والنتيجة المتوقعة، والنتيجة الفعلية، والرسالة أو القياس الذي يدعم الاستنتاج. من الأخطاء المتكررة في هذا الموضوع: اختبار تفاصيل داخلية بدل السلوك العام.. تعامل مع هذه النقطة كفرضية للفحص، لا كتشخيص مسبق؛ فقد يكون سبب المشكلة في طبقة مجاورة أو في افتراض غير صحيح بالاختبار.
قسّم النظام إلى حدود واضحة: مدخلات، ومعالجة، واعتماد خارجي، ونتيجة. اختبر كل حد على حدة قدر الإمكان، ثم نفّذ سيناريو متكاملًا. إذا أصلحت المشكلة، أضف اختبارًا يمنع رجوعها أو ملاحظة تشغيلية تساعد على كشفها مبكرًا. الهدف أن يصبح التشخيص قابلًا للتكرار من عضو آخر بالفريق، لا أن يظل مرتبطًا بذاكرة الشخص الذي اكتشف العطل.
التغطية ليست هدفًا مستقلًا
نسبة تغطية عالية قد تأتي من تنفيذ أسطر دون التحقق من النتائج المهمة. استخدم التغطية لتحديد الأجزاء التي لا تصل إليها الاختبارات، ثم اختر الحالات حسب خطورة الفشل والتغير المتوقع في الكود. ركّز على شروط الصلاحيات والحالات الحدية ومسارات الخطأ والعمليات التي تسبب أثرًا ماليًا أو فقد بيانات.
اجعل الاختبارات جزءًا من CI مع تقسيم مناسب بين السريع والبطيء. اختبارات الدخان بعد النشر يمكن أن تتحقق من المسار الأساسي دون تكرار مجموعة كاملة، لكن لا تستخدم بيئة الإنتاج لإجراء اختبارات مدمرة. حافظ على بيانات الاختبار والأسرار منفصلة عن بيانات العملاء.
اعتبارات متقدمة قبل اعتماد الحل
في المشروع الحقيقي، لا يُقيّم الحل على نجاح الحالة السعيدة فقط. راجع السلوك عند الحمل، وحالات الفشل، والتغييرات المستقبلية، والحدود الأمنية ذات الصلة. من المهم هنا أن اجعل الاختبارات قابلة للتكرار ومعزولة، واحفظ أدلة الفشل، ولا تستبدل التشخيص بإعادة المحاولة المتكررة. لا تُعامل هذه النقاط كملحق لاحق؛ فقرار التصميم قد يصعب تغييره عندما تتراكم البيانات أو يعتمد عليه عملاء متعددون.
حدّد مقاييس أو اختبارات قبول قبل الدمج، ودوّن حدود الحل بوضوح. قد يكون الحل مناسبًا لموقع صغير لكنه يحتاج طابورًا أو cache أو بنية أكثر صرامة عند نمو الاستخدام. لا تضف تعقيدًا مسبقًا بلا دليل، لكن لا تتجاهل علامة واضحة على أن المتطلبات تتجاوز النسخة البسيطة. القرار الجيد يوازن البساطة الحالية مع كلفة التغيير المتوقعة ويحافظ على وضوح النظام للفريق.
خطة لبناء ثقة تدريجية
ابدأ بأكثر السلوكيات خطورة أو تكرارًا، وأضف اختبارًا عند إصلاح خلل حتى لا يعود. قِس زمن الاختبارات، ونسبة الفشل المتقطع، والوقت اللازم لمعرفة سبب الخطأ، لا نسبة التغطية وحدها. ارفع مستوى الاختبار عند نقاط الحدود بين المكونات، مثل API وقاعدة البيانات أو المتصفح والخادم.
يجب أن يستطيع مطور جديد تشغيل الاختبارات من دليل قصير دون إعدادات سرية غير موثقة. إذا لم تكن الاختبارات سهلة التشغيل، فغالبًا ستُهمَل أو ستختلف نتائجها بين المطورين وCI، وهذا يقلل فائدتها حتى لو كانت مكتوبة جيدًا.
تطبيق عملي ومعايير قبول
جرّب هذا التمرين على مشروع تجريبي أو فرع منفصل: شغّل الاختبارات بترتيبات مختلفة وأزل انتظارًا زمنيًا ثابتًا لصالح شرط قابل للتحقق. اكتب النتيجة التي تتوقعها قبل التنفيذ، وسجّل ما حدث بالفعل، ثم أصلح الفرق إن ظهر. جرّب كذلك حالة حدودية أو فشلًا مقصودًا بصورة آمنة. لا تستخدم بيانات حقيقية أو نظامًا إنتاجيًا لإحداث فشل تجريبي.
اعتبر المهمة مكتملة عندما تكون خطوات إعادة التجربة موثقة، والاختبار يثبت السلوك الأساسي وحالة الفشل، ولا توجد أسرار أو معلومات حساسة في السجل، ويستطيع مطور آخر فهم سبب الحل. إذا لم يتحقق هذا، فالمطلوب ليس إضافة مزيد من الكود مباشرة؛ أعد صياغة المشكلة ووضح الافتراض الذي لم يكن صحيحًا. هذه الطريقة تجعل المقال نقطة انطلاق لممارسة تقنية، لا مجرد قراءة نظرية.
أسئلة شائعة عن الاختبارات الآلية
هل E2E أفضل من اختبارات الوحدة؟ ليست بديلًا؛ تختبر E2E رحلة كاملة لكنها أعلى كلفة وأصعب تشخيصًا.
هل أستخدم sleep لإصلاح اختبار غير مستقر؟ غالبًا لا؛ انتظر شرطًا واضحًا وابحث عن سبب التوقيت.
هل التغطية 100% تضمن الجودة؟ لا؛ التغطية لا تقيس وحدها قوة assertions ولا أهمية الحالات المختبرة.
خطة تطبيق عملية
- ابدأ بسلوك مهم أو bug متكرر.
- اختر طبقة الاختبار حسب موضع القاعدة.
- اجعل البيانات والبيئة قابلة للتكرار.
- اكتب assertions تتحقق من النتيجة.
- راقب الزمن والفشل المتقطع.
أخطاء شائعة انتبه لها
- اختبار تفاصيل داخلية بدل السلوك العام.
- الاعتماد على sleep ثابت في E2E.
- اعتبار نسبة التغطية برهانًا على الجودة.
الخلاصة
مجموعة فعالة تجمع سرعة اختبارات الوحدة وواقعية التكامل وثقة مسارات E2E المحددة. اختر الطبقة وفق المخاطر، واجعل الفشل مفهومًا، واستخدم كل bug فرصة لمنع الانحدار.