كانت تغطية الكود 100% خادعة: كيف كشف ‘الاختبار الطفري’ (Mutation Testing) عن عيوب اختباراتنا الصامتة؟

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحولي اليوم أحكيلكم قصة صارت معي ومع فريقي قبل فترة، قصة علّمتنا درس قاسي لكنه مهم. كنا وقتها شغالين على ميزة حساسة جداً في نظام مالي، ميزة بتتعلق بحسابات وعمليات تحويل. كالعادة، أنا وفريقي بنحب الشغل النظيف والمرتب، “شغل الإيد” زي ما بحكوها. كتبنا الكود، وبعدها انطلقنا في كتابة اختبارات الوحدات (Unit Tests).

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

أطلقنا الميزة واحنا متطمنين. لكن… بعد كم يوم، بلشت توصلنا تقارير عن أخطاء غريبة في الحسابات. أرقام مش منطقية، وحالات استثنائية (edge cases) ما كانت في الحسبان. قعدنا نراجع الكود، ونراجع الاختبارات، كل شي كان سليم ظاهرياً. كيف صار هيك واختباراتنا مغطية كل شي؟

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

ما هي تغطية الكود (Code Coverage)؟ ولماذا هي خادعة أحياناً؟

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

فهم تغطية الكود ببساطة

تخيل الكود تبعك عبارة عن بيت كبير فيه غرف وممرات. تغطية الكود بتعطيك تقرير يقول لك: “أنت مريت من 80% من غرف البيت”. هذا مؤشر جيد، أكيد أفضل من 20%. لكنه ما بجاوب على الأسئلة الأهم:

• هل لما دخلت الغرفة، تأكدت إن الشباك بيقفل كويس؟
• هل فحصت إذا في تسريب مياه تحت المغسلة؟
• هل تأكدت إن الأبواب بتفتح وبتسكر بشكل صحيح؟

تغطية الكود بتقول لك إنك “دخلت الغرفة”، لكنها ما بتعرف إيش سويت جوه. وهذا هو الوجه الخفي والمخادع لتغطية 100%.

الوجه الخفي لتغطية 100%

شوف معي هالمثال البسيط في جافاسكريبت. عنا دالة (function) بسيطة جداً المفروض تتأكد إذا الرقم موجب.

// isPositive.js
function isPositive(number) {
  return number > 0;
}

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

// isPositive.test.js
test('should run isPositive function', () => {
  isPositive(5); // <-- تم تنفيذ الدالة
});

لو شغلت أداة تغطية الكود، رح تعطيك 100% على دالة `isPositive`. ليش؟ لأن الاختبار فعلاً استدعى الدالة ونفذ السطر `return number > 0;`. لكن هل هذا اختبار حقيقي؟ طبعاً لأ!

هذا الاختبار ما تحقق من أي شي. لو غيرنا الكود الأصلي بالخطأ ليصير هيك:

// isPositive.js (With a bug)
function isPositive(number) {
  return false; // خطأ! دائماً ترجع false
}

الاختبار الضعيف السابق سيبقى ينجح (Pass)! وهنا المصيبة. أنت عندك تغطية 100% واختبارات ناجحة، لكن الكود فيه خطأ فادح. الاختبار الصحيح لازم يكون فيه “تأكيد” (Assertion):

// isPositive.test.js (Correct test)
test('should return true for positive numbers', () => {
  expect(isPositive(5)).toBe(true); // <-- نتأكد من القيمة المرجعة
});

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

الدخول إلى عالم الاختبار الطفري (Mutation Testing): المحقق الذي لا يرحم

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

ما هو الاختبار الطفري؟ (شرح مبسط)

فكرته عبقرية وبسيطة بنفس الوقت. بدل ما نختبر الكود، خلينا نختبر الاختبارات! كيف؟

تخيل إن في “عفريت برمجي” صغير وخبيث بتسلل للكود تبعك وبيعمل فيه تغييرات طفيفة جداً، تغييرات بنسميها “طفرات” (Mutations). مثلاً:

• يغير إشارة `>` إلى `>=`.
• يغير `+` إلى `-`.
• يغير `if (condition)` إلى `if (true)`.
• يحذف سطر كود بالكامل.

بعد ما العفريت يعمل طفرة، بنرجع نشغل كل اختباراتنا. هنا عنا احتمالين:

1. واحد أو أكثر من اختباراتك فشل (Failed): ممتاز! أحسنت! هذا معناه إن اختباراتك قوية كفاية ولاحظت التغيير الخبيث و”قتلت الطفرة”. بنسمي هاي “طفرة مقتولة” (Killed Mutant).
2. كل اختباراتك نجحت (Passed): يا ويل قلبي! هاي هي المشكلة. هذا معناه إن اختباراتك ضعيفة جداً لدرجة إنها ما انتبهت للتغيير اللي صار في الكود. بنسمي هاي “طفرة ناجية” (Survived Mutant). وهدفك كمبرمج هو القضاء على كل الطفرات الناجية عن طريق تحسين اختباراتك.

الاختبار الطفري ما بهمه الكود تبعك، بهمه يشوف إذا اختباراتك قادرة تصرخ وتقول “في شي غلط!” لما الكود يتغير بشكل غير متوقع.

مثال عملي: من النظرية إلى التطبيق

خلينا نطبق هالكلام على مثال حقيقي. رح نستخدم جافاسكريبت مع أداة مشهورة للاختبار الطفري اسمها Stryker.

الكود الأصلي والاختبار الضعيف

عندنا دالة بسيطة لحساب الخصم. إذا كان السعر فوق 100، بنعطي خصم 10%. غير هيك، ما في خصم.

// src/discount.js
function calculateDiscount(price) {
  if (price > 100) {
    return price * 0.10;
  }
  return 0;
}

وهذا اختبار ضعيف، لكنه يحقق تغطية 100%:

// test/discount.test.js
const { calculateDiscount } = require('../src/discount');

test('should return a number', () => {
  // نختبر حالة واحدة فقط
  expect(typeof calculateDiscount(150)).toBe('number'); 
});

test('should handle prices under 100', () => {
  // نختبر الحالة الثانية
  expect(typeof calculateDiscount(50)).toBe('number');
});

هذه الاختبارات تضمن أن الدالة تغطي كل الفروع (if and else)، وبالتالي نحصل على تغطية 100%. لكنها لا تتأكد من صحة قيمة الخصم نفسها!

تشغيل الاختبار الطفري وكشف المستور

لما نشغل أداة Stryker على هذا الكود، رح تبدأ بصنع الطفرات. واحدة من الطفرات اللي رح تعملها هي تغيير الشرط في الكود الأصلي:

طفرة محتملة: تغيير `if (price > 100)` إلى `if (price >= 100)`.

الآن، الأداة رح تشغل اختباراتنا الضعيفة على هذا الكود “المُطفّر”. شو رح يصير؟ الاختبارات رح تنجح! لأنها بتتأكد بس من نوع القيمة المرجعة (`number`)، وهذا الشرط ما زال متحقق. بالتالي، ستحصل على تقرير من Stryker يقول لك:

“Mutant Survived!”

وهنا المصيبة! الأداة بتقول لك: “انتبه! لو مبرمج بالخطأ غير `>` إلى `>=`، اختباراتك ما رح تكتشف الخطأ!”.

تصحيح الاختبار و”قتل” الطفرة

الآن، وبناءً على تقرير الاختبار الطفري، لازم نقوي اختباراتنا. لازم نتأكد من القيمة الفعلية للخصم.

// test/discount.test.js (The Strong Version)
const { calculateDiscount } = require('../src/discount');

test('should give 10% discount for prices over 100', () => {
  // نتأكد من القيمة الصحيحة
  expect(calculateDiscount(150)).toBe(15); 
  expect(calculateDiscount(200)).toBe(20);
});

test('should give no discount for prices 100 or less', () => {
  // نتأكد من الحالات الحدية (Edge Cases)
  expect(calculateDiscount(100)).toBe(0);
  expect(calculateDiscount(50)).toBe(0);
});

الآن، لو شغلنا الاختبار الطفري مرة ثانية، شو بصير لما الأداة تعمل الطفرة `if (price >= 100)`؟

اختبار `expect(calculateDiscount(100)).toBe(0)` سيفشل! لأنه مع الكود المُطفّر، `calculateDiscount(100)` رح ترجع `10` بدل `0`. وبالتالي، الاختبار بيفشل، والأداة بتسجل بفخر:

“Mutant Killed!” ✅

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

نصائح من “أبو عمر” للتعامل مع الاختبار الطفري

بعد تجربتنا مع هاي التقنية، تعلمت كم شغلة بحب أشاركها معكم:

• ابدأ بالتدريج: الاختبار الطفري بطيء جداً. لا تحاول تطبقه على كل الكود القديم مرة واحدة، رح تصيبك جلطة. ابدأ بالميزات الجديدة والحساسة. “شوي شوي يا خال”، حبة حبة.
• لا تستهدف 100% Mutation Score: على عكس تغطية الكود، الوصول لـ 100% في نتيجة الاختبار الطفري (Mutation Score) صعب جداً ومكلف من ناحية الوقت. هدف واقعي وممتاز هو 80% فما فوق على الأجزاء الحرجة من الكود. الكمال عدو الإنجاز.
• أداة مساعدة وليست بديلة: الأداة بتكشف لك نقاط الضعف، لكنها ما بتكتب لك الاختبار. أنت كمهندس برمجيات لازم تفكر وتكتب اختبارات منطقية تغطي حالات الاستخدام المختلفة. “شغّل مخك” واستخدم الأداة كمرشد.
• دمجه في الـ CI/CD بحذر: بسبب بطئه، لا تشغل الاختبار الطفري مع كل `commit`. استراتيجية أفضل هي تشغيله بشكل دوري (مثلاً كل ليلة)، أو عند عمل `pull request` للفروع الرئيسية (main/develop)، وفقط على الوحدات البرمجية (modules) التي تم تغييرها.
• حلل الطفرات الناجية: مش كل طفرة ناجية (survived mutant) معناها إن اختبارك سيء. أحياناً بتكشف لك عن كود مكرر أو كود “ميت” لا يمكن الوصول إليه. حلل التقرير جيداً قبل ما تعدل أي شي.

الخلاصة: من مطاردة الأرقام إلى بناء الثقة 🎯

الزبدة يا جماعة الخير، إن الاعتماد على تغطية الكود (Code Coverage) لوحدها هو وهم. هي مؤشر كمي، بيعطيك فكرة عن حجم الكود المختبر، لكنها ما بتقيس جودة الاختبارات نفسها.

الاختبار الطفري (Mutation Testing) هو النقلة النوعية. هو اللي بيقيس الجودة، وبيجبرنا نغير طريقة تفكيرنا من “هل الكود تم اختباره؟” إلى “هل اختباراتنا فعّالة وقوية؟”.

في عالمنا، عالم البرمجة، الثقة هي كل شيء. الثقة في منطقنا البرمجي، الثقة في فريقنا، والثقة في شبكة الأمان اللي بنبنيها حول الكود تبعنا. الاختبار الطفري مش مجرد أداة، هو فلسفة بتساعدنا نبني هاي الثقة، طفرة مقتولة ورا طفرة مقتولة.

يلا، شدوا حيلكم يا شباب، وخلينا نكتب اختبارات بتفش الغل!