تغطية الكود 100% كانت وهمًا: كيف أنقذنا ‘اختبار الطفرات’ من جحيم الاختبارات الزائفة؟

حفلة الـ 100%… التي انتهت بكارثة صامتة

خلوني أحكيلكم قصة صارت معي قبل كم سنة. كنا بنشتغل على مشروع حساس ومهم، وكان ضغط الإدارة علينا “خاوة” إنه لازم نوصل لتغطية كود (Code Coverage) بنسبة 100% في الاختبارات الآلية (Unit Tests). الفريق، وأنا منهم، اشتغل ليل نهار. كل دالة، كل سطر، وكل شرط `if` كان لازم يمر عليه اختبار.

بعد أسابيع من التعب، أخيراً، ظهر الرقم السحري على لوحة المراقبة في Jenkins: Code Coverage: 100%. يا جماعة، الفرحة اللي كانت في المكتب وقتها لا توصف. الشباب صاروا يهنوا بعض، ومدير المشروع جاب كنافة، والكل حاسس بإنجاز عظيم. شاب صغير متحمس في الفريق، اسمه “سامر”، إجا علي وهو مبتسم من الأذن للأذن وقلي: “شفت يا أبو عمر؟ ولا بق (bug) رح يفلت منا هسا!”.

ابتسمت له ابتسامة باهتة وقلت في سري: “يا ريت يا سامر، يا ريت”. كنت حاسس إنه هالفرحة وراها إشي مش مريح. الـ 100% هاي كانت حلوة على الورق، بس في شعور داخلي كان يقولي إنه هاي “فشكة فاضية”.

ما مر أسبوعين على إطلاق المشروع، إلا وبدأت توصلنا تقارير عن أخطاء غريبة في النظام. المشكلة الكبيرة كانت في دالة بسيطة مسؤولة عن حساب الخصومات. هاي الدالة بالذات كانت تغطيتها 100% ومختبرة من كل الزوايا… أو هكذا كنا نعتقد. الخطأ كان بسيطًا جدًا: بدل `price > 100` كان لازم تكون `price >= 100`. اختباراتنا كانت تستخدم أرقام مثل 90 و 110، وما حدا فكر يختبر الحالة الحدية (edge case) عند الرقم 100 بالضبط. الاختبار مر، التغطية 100%، لكن الكود كان غلط.

في ذلك اليوم، اجتمعت مع الفريق وقلتلهم: “يا جماعة، تغطية الكود 100% بدون جودة اختبارات حقيقية، زي اللي بيروح على الجيم عشان ياخذ سيلفي ويروح. الشكل من برا حلو، بس ما في عضلات حقيقية”. كانت هذه الحادثة هي الشرارة التي جعلتنا نبحث عن حل أعمق، حل يختبر اختباراتنا نفسها. وهنا، تعرفنا على عالم “اختبار الطفرات” أو الـ Mutation Testing.

وهم تغطية الكود: لماذا الـ 100% لا تعني شيئًا؟

قبل ما نغوص في الحل، خلينا نفهم أصل المشكلة. تغطية الكود، ببساطة، هي مقياس يقيس أي أجزاء من الكود الخاص بك تم “تنفيذها” أثناء تشغيل الاختبارات. لو عندك دالة من 10 أسطر، واختبارك خلى المترجم يمر على الـ 10 أسطر، فالتغطية 100%.

المشكلة: التغطية لا تقيس جودة التأكيدات (Assertions). لا يهمها إذا كنت تتأكد من النتيجة الصحيحة أم لا. كل ما يهمها هو أن السطر قد تم “زيارته”.

مثال عملي على اختبار زائف

لنفترض أن لدينا هذه الدالة البسيطة في JavaScript:

// دالة ترجع "موجب" إذا كان الرقم أكبر من صفر
function checkNumber(num) {
  if (num > 0) {
    return "موجب";
  }
  return "ليس موجب";
}

الآن، يمكن لمطور مبتدئ أن يكتب الاختبار التالي لتحقيق التغطية:

test('checkNumber should be covered', () => {
  checkNumber(10); // تم استدعاء الدالة، لكن بدون أي تأكيد!
  checkNumber(-5);
});

أداة قياس التغطية ستصرخ فرحًا: “تغطية 100%!”. لكن هل هذا الاختبار مفيد؟ بالطبع لا. لو قمنا بتغيير الدالة الأصلية لترجع `null` دائمًا، هذا الاختبار سيبقى ينجح، ولن تكتشف الخطأ إلا في مرحلة الإنتاج.

نصيحة أبو عمر: تغطية الكود هي نقطة بداية ممتازة، لكنها ليست خط النهاية. استخدمها كمؤشر للكود الذي لم يتم اختباره على الإطلاق، وليس كمقياس لجودة الكود الذي تم اختباره.

الصحوة: مرحبًا بك في عالم اختبار الطفرات (Mutation Testing)

إذًا، كيف نتأكد أن اختباراتنا ليست مجرد ديكور؟ كيف نتأكد أنها “ستصرخ” عند حدوث أي تغيير غير متوقع في الكود؟ الجواب هو اختبار الطفرات.

تخيل أن لديك “شيطانًا” صغيرًا أو “عفريتًا” (Gremlin) يعيش داخل الكود الخاص بك. وظيفته هي تغيير الكود بشكل طفيف وعشوائي ثم إعادة تشغيل الاختبارات. كل تغيير صغير يجريه هذا العفريت يسمى “طفرة” (Mutation)، والكود بعد التغيير يسمى “المتحول” (Mutant).

آلية العمل خطوة بخطوة

1. تشغيل الاختبارات الأساسية: أولاً، يتم تشغيل مجموعة الاختبارات الكاملة على الكود الأصلي. يجب أن تنجح جميعها. إذا فشل أي اختبار هنا، فهذا يعني أن لديك مشكلة في الكود أو الاختبارات من الأساس.
2. خلق الطفرات: تقوم الأداة بتغيير جزء صغير جدًا من الكود. هذه التغييرات (الطفرات) ذكية جدًا، فهي تحاكي الأخطاء الشائعة التي يقع فيها المبرمجون.
   • تغيير `>` إلى `>=` أو `<`.
   • تغيير `&&` إلى `||`.
   • حذف سطر من الكود.
   • تغيير قيمة `true` إلى `false`.
   • تغيير `+` إلى `-`.
3. تشغيل الاختبارات ضد المتحول: يتم تشغيل الاختبارات مرة أخرى على الكود الذي يحتوي على الطفرة.
4. تحليل النتيجة: هنا يكمن السحر كله.
   • 🚨 إذا فشل أحد الاختبارات (Mutant Killed): هذا ممتاز! يعني أن اختباراتك قوية بما يكفي لاكتشاف هذا التغيير الطفيف. نقول أن “المتحول قد قُتل”.
   • 🤫 إذا نجحت كل الاختبارات (Mutant Survived): هذه هي الكارثة! هذا يعني أن لديك تغييرًا خطيرًا في الكود، ولكن لم يكتشفه أي من اختباراتك. هذا يكشف عن ضعف في مجموعة اختباراتك. نقول أن “المتحول قد نجا”.

الهدف هو “قتل” أكبر عدد ممكن من المتحولين. النسبة المئوية للمتحولين الذين تم قتلهم تسمى “معدل الطفرات” (Mutation Score)، وهو مقياس أكثر واقعية بكثير لجودة اختباراتك من تغطية الكود التقليدية.

مثال عملي يوضح الفكرة

لنعد إلى مثالنا الأول عن الخصومات. كانت الدالة الأصلية تحتوي على خطأ:

function applyDiscount(price) {
  // خطأ: يجب أن تكون >=
  if (price > 100) { 
    return price * 0.9; // خصم 10%
  }
  return price;
}

وكان اختبارنا (الضعيف) كالتالي:

test('applies 10% discount for prices over 100', () => {
  expect(applyDiscount(200)).toBe(180);
});

test('does not apply discount for prices under 100', () => {
  expect(applyDiscount(50)).toBe(50);
});

هذه الاختبارات تحقق تغطية 100% لكنها لا تكشف الخطأ عند `price = 100`.

الآن، دع أداة اختبار الطفرات تعمل. أحد المتحولين الذين ستخلقهم هو:

// المتحول (Mutant)
function applyDiscount(price) {
  // تم تغيير `>` إلى `>=`
  if (price >= 100) { 
    return price * 0.9; // خصم 10%
  }
  return price;
}

عندما تقوم الأداة بتشغيل الاختبارات الحالية ضد هذا المتحول، ستنجح جميع الاختبارات! لا يوجد أي اختبار يفشل. وهنا تصرخ الأداة: “Mutant Survived!”.

هذه هي اللحظة التي تدرك فيها كـ مطور أن اختباراتك ينقصها شيء. الآن، أنت تعرف بالضبط ما يجب عليك فعله: إضافة اختبار للحالة الحدية.

// الاختبار الجديد الذي يقتل المتحول
test('does not apply discount for price exactly at 100', () => {
  // هذا الاختبار سيفشل على الكود الأصلي، وهو المطلوب!
  // أو سينجح على الكود الأصلي، ويفشل على المتحول، فيقتله.
  expect(applyDiscount(100)).toBe(100); 
});

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

دليل أبو عمر العملي للبدء مع اختبار الطفرات

الكلام النظري جميل، لكن كيف نبدأ عمليًا؟ أشهر أداة في عالم JavaScript اليوم هي Stryker. وهي متوفرة أيضًا لـ C# و Scala.

h3: الخطوات العملية مع Stryker (مثال JS)

1. التثبيت: أضف Stryker إلى مشروعك.

   npm install --save-dev @stryker-mutator/core @stryker-mutator/jest-runner

2. الإعداد: أنشئ ملف إعداد `stryker.conf.json`.

   {
     "$schema": "./node_modules/@stryker-mutator/core/schema/stryker-schema.json",
     "packageManager": "npm",
     "reporters": ["html", "clear-text", "progress"],
     "testRunner": "jest",
     "coverageAnalysis": "perTest"
   }

3. التشغيل: قم بتشغيل Stryker من سطر الأوامر.

   npx stryker run

4. تحليل التقرير: سيقوم Stryker بإنشاء تقرير HTML مفصل. هذا التقرير هو منجم ذهب. سيُظهر لك كل متحول تم إنشاؤه، وما إذا كان قد “قُتل” أو “نجا”. الأهم من ذلك، أنه سيُظهر لك الكود الدقيق الذي تسبب في نجاة المتحول، مما يتيح لك معرفة أين يجب عليك تحسين اختباراتك.

نصيحة أبو عمر من الميدان: لا تحاول الوصول إلى mutation score 100% من اليوم الأول، خاصة في المشاريع الكبيرة والقائمة. هذا الأمر مرهق وغير عملي. ابدأ بالتركيز على الأجزاء الأكثر أهمية وحساسية في تطبيقك (Core Business Logic). حدد درجة مقبولة (مثلاً 80%) واجعلها جزءًا من عملية الـ CI/CD لمنع انخفاض الجودة مع مرور الوقت.

الخلاصة: لا تختبر الكود فقط، بل اختبر اختباراتك 🧭

رحلتنا من وهم الـ 100% إلى واقعية اختبار الطفرات كانت بمثابة صحوة. تعلمنا بالطريقة الصعبة أن جودة البرمجيات ليست رقمًا يظهر على لوحة المراقبة، بل هي ثقة بأن الكود الذي كتبناه سيتصرف كما هو متوقع، وأن اختباراتنا ستحمينا كخط دفاع حقيقي وليس مجرد ديكور.

تغطية الكود تخبرك ما إذا كنت قد اختبرت الكود. اختبار الطفرات يخبرك بمدى جودة هذا الاختبار.

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