ما المقصود بالتطوير القائم على الاختبار (TDD)؟

يكتب المطورون ما يكفي من التعليمات البرمجية لتمرير كل اختبار، ثم يتم تحسين كلٍّ من الاختبار والتعليمات البرمجية قبل الانتقال إلى اختبار جديد ثم ميزة جديدة.

يفرض التطوير القائم على الاختبار على المطورين تباطؤ الإيقاع، والتحقق من تعليماتهم البرمجية وتنقيحها ضمن دورات تعليقات قصيرة. على الرغم من عدم كون ذلك إلزاميًا، تشجِّع فرق عمليات التطوير المبرمجين، من المبتدئين إلى المحترفين، على استخدام TDD عبر مجموعة واسعة من لغات البرمجة. على سبيل المثال، Java وPython وما إلى ذلك، وواجهات برمجة التطبيقات (APIs) وتطبيقات البرامج.

تعمل البرمجة بهذا الأسلوب على تعزيز العلاقة بين الترميز والاختبار (في شكل اختبارات مؤتمتة على مستوى الوحدة) وتصميم الكود. على الرغم من أن التطوير القائم على الاختبار قد يؤدي إلى زيادة وقت التطوير الأوَّلي، فقد ثبت أنه يعمل على تحسين وظائف الكود ومرونته وتوفير الوقت بشكل عام.

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

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

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

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

هناك مستويان رئيسيان للتطوير القائم على الاختبار.

بالنسبة إلى قبول TDD -والذي يُطلق عليه أحيانًا اسم Behavior-Driven Development (BDD)- يكتب المبرمجون اختبار قبول واحدًا ثم ما يكفي من التعليمات البرمجية الجديدة لتمريرها. تُعرف اختبارات القبول أحيانًا باسم اختبارات العملاء أو اختبارات قبول العملاء.

يمكن فهمها بشكل عام على أنها حالات اختبار مطلوبة للحد الأدنى من الوظائف كما هو موضَّح من قِبَل الأطراف المعنية في المنتج. تسعى ATDD إلى تحديد المتطلبات التفصيلية القابلة للتنفيذ. يمكن إجراء اختبارات القبول باستخدام أدوات اختبار مختلفة، مثل Fitnesse أو RSpec.

يُشار إليه أحيانًا ببساطة باسم TDD، حيث يتطلب تطوير TDD من المبرمجين كتابة اختبارات فردية لتقييم حلولهم الخاصة لاختبار ATDD. يستخدم مطور TDD أدوات أتمتة الاختبار، مثل JUnit أو VBUnit.

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

تنقسم عملية التطوير القائمة على الاختبار إلى خمس خطوات فردية:

1. قبل كتابة التعليمات البرمجية لوظيفة برنامج معينة، يكتب المطورون أولًا اختبار وحدة فردية لتلك الوظيفة.
2. يقوم المطورون بعد ذلك بتشغيل الاختبار، والذي من المفترض أن يفشل لأن وظيفة الكود لم تتم كتابتها بعد. تُعَد هذه الخطوة مهمة للتأكد من أن الاختبار نفسه يعمل بشكل صحيح ولا يُعطي أي نتائج إيجابية زائفة. إذا نجح الكود، فهذا يشير إلى ضرورة إعادة كتابة الاختبار.
3. عندما يفشل البرنامج في اجتياز الاختبار، يكتب المطورون فقط ما يكفي من التعليمات البرمجية الإضافية لتمرير الاختبار. 
4. عندما يتمكن الكود من اجتياز الاختبار، تتم إعادة تصميم كل من الاختبار والكود من أجل البساطة والتخلص من أي كود غير ضروري. 
5. عندما يتمكن البرنامج الذي تمت إعادة صياغته بشكل كافٍ من اجتياز اختبار إعادة الصياغة، ينتقل المطورون إلى وظيفة البرنامج المطلوبة التالية. بعد ذلك، يقوم المختبرون بكتابة وتشغيل الاختبارات لكل ميزة جديدة. 

ببساطة، تتَّبِع عملية التطوير القائمة على الاختبار حلقة قابلة للتكرار، يُشار إليها بدورة إعادة البناء الأحمر والأخضر. وخطوات الدورة هي:

• أحمر: كتابة اختبار فاشل للسلوك المقصود للبرنامج. 

• أخضر: كتابة ما يكفي من الإضافات لاجتياز الاختبار.

• إعادة الصياغة: تنقيح الكود لتلبية معايير البساطة قدر الإمكان مع الاستمرار في اجتياز الاختبار.

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

تطوَّر التطوير القائم على الاختبار من وإلى جانب العديد من أطر عمل الاختبار الجديدة وتم اعتماده كمكون معياري في العديد من أطر العمل الأخرى أيضًا. الأمر الأكثر أهمية هو أن TDD مدرج في مفهوم Extreme Programming (XP)، وهو إطار عمل لتطوير البرامج الرشيقة تم تطويره لتحسين جودة البرامج وجودة الحياة للمطورين.

تُنسَب إلى مهندس البرمجيات Kent Beck، أحد الشخصيات البارزة في مجتمع الأسلوب الرشيق ومبتكر البرمجة القصوى (Extreme Programming)، "إعادة اكتشاف" تطوير البرمجيات القائم على الاختبار (TDD). على حد تعبير Beck نفسه: 

"كان الوصف الأصلي لعملية TDD موجودًا في كتاب قديم عن البرمجة. يقول إنه عليك أخذ شريط الإدخال، ثم كتابة شريط الإخراج الذي تتوقعه يدويًا، ثم برمجته حتى يتطابق شريط الإخراج الفعلي مع الإخراج المتوقع. بعد أن كتبت إطار عمل xUnit الأول في Smalltalk، تذكرت قراءة هذا وجربته. كان هذا هو أصل TDD بالنسبة لي. عند وصف TDD للمبرمجين الأكبر سنًا، كثيرًا ما أسمع، " بالطبع. وإلا كيف يمكنك البرمجة؟" لذلك، أشير إلى دوري باسم "إعادة اكتشاف" TDD". 

تتضمن التواريخ البارزة في تطوُّر التطوير القائم على الاختبار ما يلي:

• 1976: نشر Glenford Myers كتابه Software Reliability، والذي يزعم فيه أن "المطوِّر ينبغي له عدم اختبار الكود الخاص به أبدًا". ورغم أن Myers ربما لم يكن مبتكر هذا المفهوم، إلا أن عمله أعطى مصداقية لفكرة شائعة من شأنها أن تنتشر لسنوات قادمة. 

• 1990: في بداية العقد، سيطرت تقنية "الصندوق الأسود" على اختبار البرمجيات. في هذا النوع من إطار عمل الاختبار، يتعامل المختبرون مع البرنامج كما لو كان "صندوقًا أسود" وغير قابل للاختراق وغير معروف. يوظِّف اختبار الصندوق الأسود مختبرين، بشكل حاسم، ليس لديهما معرفة بالأعمال الداخلية للبرنامج. 

• 1994: قام Kent Beck بتطوير SUnit، وهو إطار عمل اختبار Smalltalk، ما أرسى الأساس لنهج الاختبار أولًا لتحسين قاعدة التعليمات البرمجية. 

• 1999 - 2002: مع تطوُّر حركة تطوير الأسلوب الرشيق، طوَّر Kent Beck مفهوم البرمجة القصوى (Extreme Programming)، حيث صاغ تطوير البرمجيات القائم على الاختبار وقدَّم مفهوم الكائنات الوهمية (mock objects) الحيوي. يستخدم TDD كائنات وهمية لمحاكاة سلوكيات التبعيات الحقيقية (على سبيل المثال، قواعد البيانات والخدمات الخارجية وما إلى ذلك) أثناء الاختبار. تساعد هذه الطريقة المطورين على تركيز كود الاختبار الخاص بهم على كائنات وهمية قابلة للصيانة يمكن التحقق من أدائها بدقة. يمكن أن يؤدي الاختبار الفاشل الذي يستخدم كائنًا وهميًا إلى التخلص من الاعتماد الذي تم تكوينه بشكل غير صحيح كمصدر للفشل. 

• 2003: نشر Kent Beck كتاب "Test Driven Development: By Example"، ما أدى إلى نشر هذه الممارسة بين مجتمع التطوير الأوسع وإضفاء المزيد من الشرعية على الاختبار بقيادة المطوِّر. 

كجزء من البرمجة القصوى (Extreme Programming)، تبيَّن أن تطوير البرمجيات القائم على الاختبار (TDD) مفيد ليس فقط لإنتاج كود أفضل، بل أيضًا لصقل مهارات المطورين أنفسهم. يُتيح TDD للمطورين فهم مشاريعهم بشكل أفضل ويساعد على توجيه تصميم البرنامج. من خلال وضع حالة الاختبار في المقام الأول قبل تنفيذ كل ميزة، يضطر المطورون إلى تصوُّر كيفية استخدام الوظيفة من قبل العميل أو المستخدم. تضع هذه الطريقة واجهة المنتج قبل التنفيذ، ما يساعد المطورين على إنشاء تطبيقات أكثر تركيزًا على المستخدم. 

تتضمن بعض الفوائد الإضافية للتطوير القائم على الاختبار ما يلي:

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

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

• تحسين الثقة: يكتسب المطورون وفرق عمليات التطوير الذين يستخدمون نهج TDD ثقة أكبر ليس فقط في التعليمات البرمجية الخاصة بهم ولكن أيضًا في اختباراتهم. 

• تسهيل التكامل المستمر: يُعَد TDD مناسبًا جدًا لممارسات التكامل المستمر، حيث يتم تحديث الكود المباشر باستمرار بميزات وتحديثات جديدة. 

• تقليل التصحيح: اختبار TDD للأحمال الأمامية في عملية التطوير، ما يقلل من الحاجة إلى تصحيح شامل في نهاية التطوير. 

• تحسين وضوح المتطلبات: يساعد TDD المطورين على إنشاء فهم واضح لكل متطلبات البرنامج المحددة قبل بدء العمل. 

• تحسين الإنتاجية: غالبًا ما يرتبط تطوير TDD بزيادة الإنتاجية بين المطورين حيث تساعد العملية على تجزئة المشاريع الكبيرة إلى خطوات أصغر وأكثر قابلية للتحقيق. 

• تعزيز التصميم البسيط: تتطلب الخطوة الثالثة الحاسمة في دورة TDD إعادة صياغة وتبسيط التعليمات البرمجية الخاصة بهم من المطورين. تعمل هذه الممارسة على تحسين البساطة العامة وجودة التصميم. 

• تعزيز النماذج الذهنية: من خلال فحص كل وظيفة أو متطلب فريد ودمجها، يساعد TDD المبرمجين على تطوير نموذج ذهني قوي للكود الموجود بين أيديهم. يساعد هذا النموذج العقلي المطورين على تصوُّر الوظائف والمتطلبات العامة للكود أثناء عملهم عليها. 

• تحسين استقرار النظام: لقد ثبت أن استخدام التطوير القائم على الاختبار يحسِّن استقرار التطبيق بشكل عام من خلال إنشاء تعليمات برمجية قوية تم اختبارها جيدًا وتتماشى مع معايير عالية للبساطة في التصميم. 

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

• زيادة حجم التعليمات البرمجية: يتطلب TDD من المبرمجين كتابة التعليمات البرمجية لكل ميزة مطلوبة، وكذلك أيضًا إجراء اختبارات لكل ميزة. تؤدي إضافة كود الاختبار مع كود المنتج إلى إنشاء قاعدة بيانات تعليمات برمجية إجمالية أكبر. 

• الثقة الزائفة: عندما تتم كتابة كل ميزة لاجتياز اختبار، فقد يكتسب المطورون ومديرو المشاريع إحساسًا زائفًا بالأمان تجاه وظيفة الكود ككل. رغم أن كل ميزة مدمجة يتم اختبارها، إلا أن TDD لا يُغني عن الحاجة إلى ضبط الجودة النهائي واختبار واجهة برمجة التطبيقات (API testing). 

• زيادة النفقات العامة: يتطلب TDD أن يحتفظ المبرمجون أيضًا بمجموعة كبيرة من الاختبارات بالإضافة إلى كود الإنتاج الخاص بهم. يتطلب الحفاظ على قواعد التعليمات البرمجية للاختبار قدرًا معينًا من الموارد ويمكن أن يزيد من التكاليف العامة. 

• انخفاض الكفاءة: على الرغم من أن TDD أثبت أنه يحسِّن الإنتاجية، إلا إنه قد يؤدي إلى تأخير تطوير المشروع لأنه يضيف المزيد من الخطوات إلى إنشاء كل ميزة جديدة وتنفيذها. 

• زيادة وقت الإعداد: يتطلب TDD من المطورين إعداد بيئات اختبار مناسبة للكود والحفاظ عليها. 

• إهمال التصميم العام: على الرغم من أن TDD يشجِّع على بساطة التعليمات البرمجية وتحسين التصميم، إلا أن التركيز المفرط على العناصر الفردية يمكن أن يؤدي إلى كود عام أقل تناسقًا. يحتاج المبرمجون الذين يستخدمون TDD إلى معرفة كيفية تكامل تحديثات الميزات الفردية الخاصة بهم عند تجميعها في تطبيق البرنامج الشامل.