كتابة الـ tests في صناعة البرمجيات ليست رفاهية (على الأقل كما كنت أظن سابقًا).

الكود الذي لم يتم اختباره، على الأقل في الـ correct path و الـ wrong path، هو كود قابل بنسبة كبيرة لأن يُنتج أخطاء - كثيرة- bugs مستقبلاً بشكل قطعي.

ناهيك عن الـ nested cases التي من الصعب اختبارها كاملة، لكن على الأقل الـ happy/unhappy path هي ضرورة.

لماذا؟

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

أيضًا كتابة الاختبارات تجعلك تفهم التغييرات التي قمت بها بشكل أعمق، وربما أثناء كتابة اختبار ما، تظهر لك أشياء يجب أن تغيّرها في الكود الذي كتبته و تحاول اختباره.

خلاصةً، الاختبارات ليست رفاهية.. اكتبها حتى لو لم تكن مطلوبة منك، وحتى لو لم تكن هناك عملية تشغيل للاختبارات على السيرفر أو قبل الـ deployment.

الإختبارات ستجعلك مبرمجا أفضل.

#tests #unittests

مرة أخرى؛ اكتب الـ Unit Tests، أو حتى استخدم ال AI لكتابتها،، ستحتاج في النهاية إلى جعل الاختبارات تمر بنجاح وتصحيح أخطاء الذكاء الاصطناعي لو وجدت.. ومن خلال هذه العملية ستربح الآتي:

- فهم أعمق لل function/class/behavior الذي تريد كتابته/كتابة test له في حالة عدم استخدامك لل TDD، وطريقة اختباره بشكل أفضل.

- اكتشاف الـ bugs مبكرًا قبل الوصول إلى ال production.

- تعلم التفكير في مختلف السيناريوهات المحتملة.

- اكتساب خبرة في ال testing داخل الـ framework أو لغة البرمجة التي تستخدمها.

- معرفة كيفية عمل mocking لل data وكيفية تنفيذ request/response داخل الاختبارات.

- تطوير مهاراتك في كتابة ال assertions.


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

#testing #tdd #unittests