سرعة مجموعة الاختبارات وموثوقيتها

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

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

القياس قبل التحسين

يكتب Surefire ملف XML لكل صنف اختبار في target/surefire-reports، مع مدة كل دالة. يكفي ترتيب النتائج تنازليًا حسب المدة لتحديد المتسببين في البطء.

# أبطأ 15 اختبارًا، في جميع الأصناف
grep -h '<testcase' target/surefire-reports/*.xml \
  | sed -E 's/.*name="([^"]+)".*classname="([^"]+)".*time="([^"]+)".*/\3 \2#\1/' \
  | sort -rn | head -15