بعد أن عرفنا ما هو اختبار الوحدة؟، يبقى سؤال: كم اختبارًا نكتب من كل نوع، وأين نستثمر جهدنا؟ هرم الاختبار (Testing Pyramid) نموذج بسيط يجيب عن ذلك ويوجّه استراتيجية الاختبار في أي مشروع.
ما هو هرم الاختبار؟
هرم الاختبار نموذج ذهني يصف كيف ينبغي توزيع اختباراتك على ثلاث طبقات، من الأكثر عددًا في القاعدة إلى الأقلّ في القمّة:
▲ الطرفي (E2E) ← الأقلّ عددًا، الأبطأ، الأغلى
▲▲▲ التكامل (Integration)
▲▲▲▲▲ الوحدة (Unit) ← الأكثر عددًا، الأسرع، الأرخص
الفكرة: اجعل معظم اختباراتك وحداتٍ سريعة، وأقلّها اختباراتٍ طرفيّة بطيئة.
الطبقات الثلاث
- اختبار الوحدة (Unit): يفحص قطعة صغيرة معزولة (دالّة واحدة غالبًا) بلا اعتماد على قاعدة بيانات أو شبكة. سريع جدًا وحتمي، لذا يشكّل قاعدة الهرم العريضة.
- اختبار التكامل (Integration): يفحص تعاون عدّة مكوّنات معًا — مثلًا دالّة مع قاعدة بيانات حقيقية، أو خدمتان تتحادثان. أبطأ من اختبار الوحدة وأقلّ عددًا، لكنّه يكشف مشكلات لا تظهر في العزل (مثل خطأ في استعلام أو في التوافق بين مكوّنين).
- الاختبار الطرفي (End-to-End): يفحص التطبيق كاملًا من منظور المستخدم: يفتح الواجهة، ينقر، ويتحقّق من النتيجة عبر كامل المكدّس. الأقرب إلى تجربة المستخدم الحقيقية، لكنّه الأبطأ والأغلى والأكثر عرضة للتقلّب (Flakiness).
لماذا هذا الشكل تحديدًا؟
الشكل يعكس مفاضلة بين السرعة والتكلفة والثقة:
- كلما نزلت في الهرم: اختبارات أسرع وأرخص وأسهل تشخيصًا عند الفشل (تعرف بالضبط أي دالّة أخطأت).
- كلما صعدت: ثقة أقرب لتجربة المستخدم، لكن بطء أكبر وتقلّب أعلى وصعوبة أكبر في تحديد سبب الفشل.
لذا نستثمر بكثافة في القاعدة السريعة، ونحتفظ بعدد قليل مدروس من اختبارات القمّة للمسارات الحرجة فقط.
مضادّ النمط: مخروط الآيس كريم
الخطأ الشائع هو قلب الهرم: اختبارات طرفيّة كثيرة وقليل من اختبارات الوحدة. يُسمّى هذا مخروط الآيس كريم (Ice-cream Cone)، ونتيجته:
- مجموعة اختبارات بطيئة تُعطّل دورة التطوير.
- اختبارات متقلّبة تفشل عشوائيًا فيفقد الفريق الثقة بها.
- صعوبة تشخيص الأعطال، لأنّ الاختبار الطرفي يخبرك أنّ «شيئًا ما» أخطأ دون تحديد موضعه.
التوزيع العملي
لا توجد نسبة مقدّسة، لكن التوجيه العملي: الأغلبية اختبارات وحدة، طبقة أوسط أصغر من اختبارات التكامل، وقلّة من الاختبارات الطرفيّة للتدفّقات الأهمّ (مثل التسجيل أو الدفع). المبدأ الأهمّ ليس الأرقام بل الشكل: كثيرٌ سريعٌ في الأسفل، قليلٌ بطيءٌ في الأعلى.
ℹ️ الهرم دليل استرشادي لا قانون صارم؛ طبيعة المشروع قد تعدّل النسب، لكن قلب الهرم رأسًا على عقب يكاد يكون دائمًا مؤشّر مشكلة.
الخطوات التالية
بعد استيعاب توزيع الاختبارات، ستنتقل إلى: التطوير الموجَّه بالاختبار (TDD)، ثم كتابة أوّل اختبار عملي، واختبار التكامل، والاختبار الطرفي بأدوات حديثة. راجع دائمًا الأساس في ما هو اختبار الوحدة؟، وشاهد الاختبار في سياق عملي في الاختبار في React والاختبار في Node.js.