الTest-driven development (TDD))، هو مصطلح يطلق على إحدى عمليات تطوير البرمجيات التي تعتمد على تكرار دورة تطوير قصيرة جداً: بدايةً، يقوم المبرمج بكتابة حالة فحص أوتوماتيكية فاشلة ويجب على حالة الفحص هذه أن تعرّف تحسينا معينا أو وظيفة جديدة. ومن ثم يقوم بكتابة الشيفرة التي تجعل حالة الفحص ناجحة وأخيرا يقوم بإعادة تصنيع الشيفرة كي تتلاءم مع المعايير.
المصدر
من أهداف الـ TDD الأساسية إنك تكتب ال Unit tests. الهدف ده كويس، بس مش شايف إن الـ TDD أحسن طريقة لتحقيقه. ليه؟
التصميم الاستراتيجي مقابل تكتيكات الـ Test-Driven
مشاريع البرمجيات، خصوصًا الكبيرة والمتوسطة، محتاجة تصميم قوي عشان تستحمل التغييرات اللي أكيد هتحصل. عشان نعمل كده، بنبدأ بتصميم المشروع بشكل استراتيجي.
تصميم البرمجيات بيبص على النظام كله الأول، وبعدين يتعمق في كل جزء إزاي هيشتغل مع بعض. ده بيتطلب إننا نفكر في الهيكل (الصورة الكبيرة - استراتيجي) قبل ما ندخل في أصغر الأجزاء (اللي بتهتم بيها اختبارات الوحدة). وكل ما أفكار التصميم تنضج، الهيكل بيبقى أوضح وأكثر تفصيلاً.
تصميم البرمجيات عملية مستمرة، بتبدأ عادةً بالرسومات التخطيطية، و RFCs، (ربنا ما يوريك) UML. كل ما تتعمق في المشكلة أكتر، بتظهر تفاصيل أكتر، وبتلاقي جانب تاني لازم تاخده في الاعتبار. النمو ده مش دايمًا سلس، بس عادةً بيتوسع مع الوقت. خلال العملية المتطورة دي، الكود بيتكتب ويتغير ويتعاد استخدامه باستمرار. طريقة الـ TDD هتخلينا أقل قدرة على التكيف، وهتبطئنا وهتضر بالإنتاجية.
الـ TDD ممكن تكون دليل لقرارات تصميم صغيرة، وفي بعض المواقف الحقيقية بتتطلب إنك تكون حليت المشكلة بالفعل أو أغلبها في دماغك (حتى لو بيقولوا إنها مش كده). شرط "الاختبار أولاً" ده مش مناسب لما يكون التصميم أكبر وبيتغير في الحجم.
بخبرة أكتر من سبع سنين في البرمجيات (مش كتير، عارف، بس مش قليل برضه)، وشغلي على مشاريع مختلفة لشركات كتير، مش فاكر مشروع واحد كان متحدد بالكامل أو حتى أغلبه من البداية. الحاجات كانت بتتغير باستمرار. البدء بالاختبارات الأول بيخلي الهدف الأساسي من التطوير هو مجرد اجتياز الاختبارات. التركيز بيتحول للحصول على "علامات صح خضرا" على الشاشة، وبننسى حل تصميم المنتج بشكل عام.
مع ذلك، أنا بحب ال Unit tests! بستخدمها عشان أحمي الكود بتاعي (أو على الأقل جزء كبير منه) من المستقبل الغامض والتغييرات اللي لسه مش ناضجة.
وأيوه، كتابتها مش ممتعة أوي (على الأقل بالنسبة لي). بس مش لازم أستمتع بيها عشان أشوف قيمتها. الجزء المفضل عندي هو لما اختبار كتبته يفشل بعد ما أبوظ حاجة أثناء الكودنج. ده حماية عظيمة، بتمنع الأخطاء البسيطة إنها تبقى مشاكل إنتاج كبيرة. أفضل إني أشوف نص أحمر على شاشتي بدل مشكلة ضخمة بسبب أخطائي الساذجة.
بالنسبة لي، اختبارات الوحدة بتظهر عادةً بعد ما يتم صياغة الكود الأولي لوحدة أو ميزة، أو أحيانًا في دورات قصيرة جدًا جنب الكود لما تصميمه يستقر، لكن أبدًا مش كقوة دافعة أولية.
أنا بحب التطوير بتاعي يكون مدفوع بالاستراتيجية مش بالنص الأخضر.
المقال الأصلي:
