مقدمة إلى الاختبارات الوحدوية (Unit Testing)

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

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

تخيل معي هذا السيناريو: لقد قضيت أسابيع في بناء ميزة جديدة رائعة في تطبيقك. بعد الكثير من العمل الشاق، قمت أخيرًا بنشرها. في البداية، كل شيء يبدو رائعًا. لكن بعد ساعات قليلة، تبدأ تقارير الأخطاء بالظهور من المستخدمين. ميزة قديمة، لا علاقة لها بما قمت ببنائه، توقفت عن العمل فجأة. الآن عليك أن توقف كل شيء، وتبدأ عملية مؤلمة للبحث عن سبب المشكلة تحت ضغط كبير.

هذا السيناريو المحبط هو واقع يعيشه الكثير من المطورين. الاختبارات البرمجية، وتحديدًا الاختبارات الوحدوية (Unit Testing)، هي خط دفاعك الأول لمنع حدوث ذلك.

لماذا نهتم بكتابة الاختبارات؟

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

1. الثقة والجودة (Confidence and Quality)

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

2. إعادة الهيكلة بأمان (Safe Refactoring)

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

بدون اختبارات، تكون عملية الـ Refactoring محفوفة بالمخاطر. إنها تشبه محاولة تغيير أساسات مبنى دون معرفة ما إذا كان ذلك سيؤدي إلى انهيار الجدران. أما مع وجود الاختبارات، فيمكنك إجراء أي تغيير تريده، ثم تشغيل الاختبارات للتأكد من أنك لم تفسد أي وظيفة من وظائف التطبيق. إذا اجتازت جميع الاختبارات، فأنت تعلم أن التغييرات التي أجريتها آمنة.

3. تقليل الأخطاء (Reducing Bugs)

من الطبيعي أن يحتوي الكود على أخطاء (Bugs). الهدف هو اكتشاف هذه الأخطاء في أبكر وقت ممكن. كلما اكتشفت الخطأ مبكرًا، كان إصلاحه أسهل وأقل تكلفة. اكتشاف خطأ أثناء كتابة الكود على جهازك أسهل بآلاف المرات من اكتشافه بعد أن يصل إلى المستخدمين في بيئة الإنتاج (Production).

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

4. التوثيق الحي (Living Documentation)

هل سبق لك أن نظرت إلى دالة كتبها شخص آخر (أو كتبتها أنت بنفسك منذ ستة أشهر) وتساءلت: "ماذا تفعل هذه الدالة بالضبط؟" التعليقات والمستندات يمكن أن تساعد، لكنها غالبًا ما تصبح قديمة وغير متزامنة مع الكود الفعلي.

الاختبارات هي أفضل شكل من أشكال التوثيق. إنها "توثيق حي" لا يكذب أبدًا. إذا أردت أن تعرف كيف تعمل دالة ما، ما عليك سوى قراءة اختباراتها. ستخبرك الاختبارات بالآتي:

• ما هي المدخلات التي تتوقعها الدالة؟
• ما هي المخرجات التي يجب أن تنتجها؟
• كيف تتصرف في الحالات الخاصة أو عند حدوث خطأ؟

على عكس التعليقات، إذا تغير سلوك الدالة ولم تقم بتحديث اختباراتها، فستفشل الاختبارات، مما يجبرك على مزامنتها مع الكود.

ما الذي يجعل الاختبار "جيدًا"؟

الآن بعد أن اقتنعنا بأهمية الاختبارات، من المهم أن نعرف أن ليست كل الاختبارات متساوية. هناك خصائص معينة تميز الاختبار الجيد عن الاختبار السيئ. غالبًا ما يتم تلخيص هذه الخصائص في مبدأ FIRST:

• F - Fast (سريع): يجب أن تعمل الاختبارات بسرعة فائقة. كجزء من عملية التطوير، ستقوم بتشغيلها مئات المرات في اليوم. إذا كانت بطيئة، فستتوقف عن تشغيلها، وتفقد كل الفوائد التي تحدثنا عنها.

• I - Isolated (معزول): يجب أن يكون كل اختبار مستقلًا تمامًا عن الاختبارات الأخرى. يجب ألا يعتمد نجاح أو فشل اختبار ما على اختبار آخر تم تشغيله قبله. هذا يضمن أنك عندما ترى اختبارًا فاشلاً، فإن المشكلة تكمن في الوحدة التي يتم اختبارها، وليس في مكان آخر.

• R - Repeatable (قابل للتكرار): يجب أن يعطي الاختبار نفس النتيجة في كل مرة يتم تشغيله فيها، بغض النظر عن البيئة (جهازك، جهاز زميلك، خادم الـ CI/CD). يجب ألا يعتمد على عوامل خارجية مثل الشبكة أو التاريخ والوقت الحالي.

• S - Self-Validating (ذاتي التحقق): يجب أن يكون الاختبار قادرًا على تحديد نجاحه أو فشله بنفسه. يجب ألا يتطلب أي تدخل يدوي للتحقق من النتيجة. عادةً ما ينتهي كل اختبار بـ "تأكيد" (Assertion) يقارن النتيجة الفعلية بالنتيجة المتوقعة.

• T - Timely (في الوقت المناسب): يجب كتابة الاختبارات في الوقت المناسب، ويفضل أن يكون ذلك قبل أو أثناء كتابة الكود الذي تختبره، وليس بعد فترة طويلة.

لفهم جوهر الاختبار، انظر إلى هذا المثال البسيط جدًا الذي لا يستخدم أي مكتبة اختبار. إنه يوضح الفكرة الأساسية:

// The function we want to test (our "unit")
function calculateDiscount(price, percentage) {
  if (percentage < 0 || percentage > 100) {
    throw new Error('Invalid percentage');
  }
  return price * (percentage / 100);
}

// A conceptual test for this function
console.log('Testing calculateDiscount...');

// Test Case 1: A standard discount calculation
const actualResult = calculateDiscount(200, 10); // should be 20
const expectedResult = 20;

if (actualResult !== expectedResult) {
  // If the result is not what we expect, the test fails
  throw new Error(`Test Case 1 Failed! Expected ${expectedResult}, but got ${actualResult}`);
} else {
  // Otherwise, the test passes
  console.log('  ✓ Test Case 1 Passed!');
}

هذا الكود يجسد الفكرة الأساسية: تشغيل الكود بمدخلات معروفة ومقارنة الناتج الفعلي بالناتج المتوقع. جميع أطر عمل الاختبارات (Testing Frameworks) التي سنتعلمها تقوم بأتمتة هذه العملية وتجعلها أكثر قوة وسهولة.

الخلاصة

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

تذكر النقاط الرئيسية:

• الاختبارات تمنحك الثقة لإجراء التغييرات وتطوير الكود بسرعة.
• إنها أفضل وسيلة للقيام بعملية إعادة هيكلة (Refactoring) آمنة.
• تعمل كشبكة أمان لاكتشاف الأخطاء مبكرًا، عندما يكون إصلاحها سهلاً.
• تعتبر أفضل شكل من أشكال التوثيق الحي للكود الخاص بك.

في الدرس التالي، سنقوم بتعريف "الاختبار الوحدوي" (Unit Test) بشكل أكثر تحديدًا، وسنستكشف الأنواع المختلفة من الاختبارات، ولماذا سنبدأ رحلتنا مع هذا النوع بالذات. استعد للانتقال من "لماذا" إلى "ماذا"!