حقيقة قوية.

انظر إلى الكود التالي البسيط والمباشر:

function sum(a, b) {
  return a   b;
}

الآن، دعونا نكتب بعض الاختبارات له:

test('sum', () => {
  expect(sum(1, 2)).toBe(3);
  expect(sum(2, 3)).toBe(5);
  expect(sum(3, 4)).toBe(7);
  expect(sum(4, 5)).toBe(9);
});

لقد حصلنا على تغطية 100%، أليس كذلك؟ حسنًا، نعم، نحن نفعل ذلك، في الواقع يمكننا القول أننا حصلنا على تغطية بنسبة 400% حيث تم اختبار جميع الأكواد بالكامل 4 مرات، ولكن هل نفعل ذلك؟

الحقيقة هي أننا لا نفعل ذلك. نحن نختبر الدالة باستخدام مجموعة محدودة من المدخلات، ولا نفكر في حالات الحافة، ولا نختبر الدالة باستخدام مدخلات غير صالحة.

خذ بعين الاعتبار ما يلي:

sum(1, '2');
sum(1, null);
sum(1, undefined);

ماذا سيحدث في مثل هذا السيناريو؟ هل ستلقي الوظيفة خطأ؟ هل ستعيد قيمة؟ هل سيؤدي ذلك إلى كسر طلبنا؟

انتبه إلى فخ تغطية الاختبار.

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

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

خاتمة

كانت هذه مقالة قصيرة جدًا، وأعترف أنني آمل أن تكون مفيدة لك كتذكير بأهمية كتابة اختبارات جيدة. تذكر أن تغطية الاختبار هي أداة وليست هدفًا. الأمر متروك لك لتحقيق أقصى استفادة منه.

اتصال،

مايكل.