التطوير القائم على الاختبار

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

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

عندما يعتمد الكود قيد التطوير على تبعيات خارجية، يشجع منهج تطوير البرمجيات الموجه بالاختبار (TDD) على استخدام بدائل الاختبار للحفاظ على اختبارات وحدة سريعة ومعزولة. ^{[ 13 ]} يتضمن النهج المعتاد استخدام واجهات لفصل التبعيات الخارجية وتنفيذ بدائل الاختبار لأغراض الاختبار.

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

في منهجية تطوير البرمجيات الموجهة بالاختبار (TDD)، تُعرَّف الوحدة عادةً بأنها فئة، أو مجموعة من الدوال المترابطة تُسمى غالبًا وحدة نمطية. ويُزعم أن الحفاظ على صغر حجم الوحدات يوفر فوائد بالغة الأهمية، منها:

• تقليل جهد تصحيح الأخطاء - عند اكتشاف حالات فشل الاختبار، فإن وجود وحدات أصغر يساعد في تتبع الأخطاء.
• الاختبارات ذاتية التوثيق – حالات الاختبار الصغيرة أسهل في القراءة والفهم. ^{[ 11 ]}

يمكن أن تؤدي الممارسات المتقدمة لتطوير البرمجيات الموجه بالاختبار إلى تطوير البرمجيات الموجه باختبارات القبول (ATDD) وتحديد المواصفات بالأمثلة ، حيث تُحوّل المعايير التي يحددها العميل تلقائيًا إلى اختبارات قبول، والتي بدورها تُوجّه عملية تطوير البرمجيات التقليدية الموجهة باختبارات الوحدة (UTDD). ^{[ 14 ]} تضمن هذه العملية للعميل آليةً آليةً لتحديد ما إذا كان البرنامج يلبي متطلباته. مع ATDD، يصبح لدى فريق التطوير هدفٌ محددٌ يسعى لتحقيقه، ألا وهو اختبارات القبول، مما يُبقي تركيزهم مُنصبًا باستمرار على ما يريده العميل فعلاً من كل قصة مستخدم.

يضمن التصميم الفعال لحالة الاختبار إتمام جميع الإجراءات المطلوبة، ويُحسّن من سهولة قراءة حالة الاختبار، ويُسهّل عملية التنفيذ. كما يُساعد الهيكل المتسق في بناء حالة اختبار موثقة ذاتيًا. يتكون الهيكل الشائع لحالات الاختبار من: (1) الإعداد، (2) التنفيذ، (3) التحقق، و(4) التنظيف.

• الإعداد: ضع الوحدة قيد الاختبار (UUT) أو نظام الاختبار ككل في الحالة المطلوبة لتشغيل الاختبار.
• التنفيذ: قم بتشغيل/توجيه وحدة الاختبار لتنفيذ السلوك المستهدف والتقاط جميع المخرجات، مثل القيم المُعادة ومعاملات الإخراج. عادةً ما تكون هذه الخطوة بسيطة للغاية.
• التحقق: تأكد من صحة نتائج الاختبار. قد تشمل هذه النتائج مخرجات صريحة تم التقاطها أثناء التنفيذ أو تغييرات الحالة في وحدة الاختبار.
• التنظيف: استعادة وحدة الاختبار أو نظام الاختبار ككل إلى حالته قبل الاختبار. تسمح هذه الاستعادة بتنفيذ اختبار آخر مباشرةً بعد هذا الاختبار. في بعض الحالات، وللحفاظ على المعلومات لتحليل حالات فشل الاختبار المحتملة، يجب أن يبدأ التنظيف الاختبار مباشرةً قبل تشغيل إعداد الاختبار. ^{[ 11 ]}

من أفضل الممارسات التي يمكن اتباعها فصل منطق الإعداد والإنهاء المشتركين إلى خدمات دعم اختبار تستخدمها حالات الاختبار المناسبة، مع التركيز على النتائج الضرورية فقط للتحقق من صحة الاختبار، وتصميم اختبارات مرتبطة بالوقت تسمح بالتسامح مع التنفيذ في أنظمة تشغيل غير فورية. يقلل السماح بهامش تأخير بنسبة 5-10% من احتمالية النتائج السلبية الخاطئة في تنفيذ الاختبار. كما يُنصح بالتعامل مع كود الاختبار بنفس الاهتمام الذي يُولى لكود الإنتاج. يجب أن يعمل كود الاختبار بشكل صحيح في كلتا الحالتين (الإيجابية والسلبية)، وأن يدوم لفترة طويلة، وأن يكون سهل القراءة والصيانة. يمكن للفرق الاجتماع ومراجعة الاختبارات وممارسات الاختبار لتبادل التقنيات الفعالة واكتشاف الممارسات الخاطئة. ^{[ 15 ]}

• إن وجود حالات اختبار تعتمد على حالة النظام التي تم التلاعب بها من حالات الاختبار التي تم تنفيذها مسبقًا (أي، يجب عليك دائمًا بدء اختبار الوحدة من حالة معروفة ومُهيأة مسبقًا).
• التبعيات بين حالات الاختبار. مجموعة الاختبارات التي تعتمد فيها حالات الاختبار على بعضها البعض تكون هشة ومعقدة. لا ينبغي افتراض ترتيب التنفيذ. إعادة هيكلة حالات الاختبار الأولية أو بنية وحدة الاختبار الأساسية تُسبب سلسلة من التأثيرات المتزايدة الانتشار في الاختبارات المرتبطة بها.
• الاختبارات المترابطة. قد تتسبب الاختبارات المترابطة في سلسلة من النتائج السلبية الخاطئة. يؤدي فشل حالة اختبار مبكرة إلى فشل حالة اختبار لاحقة حتى لو لم يكن هناك خطأ فعلي في وحدة الاختبار، مما يزيد من جهود تحليل العيوب وتصحيحها.
• اختبار التنفيذ الدقيق أو التوقيت أو الأداء.
• بناء "أنظمة استدلال شاملة المعرفة". نظام الاستدلال الذي يُجري عمليات فحص أكثر من اللازم يكون أكثر تكلفة وأكثر هشاشة مع مرور الوقت. هذا الخطأ الشائع خطير لأنه يتسبب في استنزاف خفي ولكنه شامل للوقت في جميع مراحل المشروع المعقد. ^{[ 15 ]}
• تفاصيل تنفيذ الاختبار.
• الاختبارات بطيئة التشغيل.

تطوير البرمجيات الموجه بالاختبار (TDD) مرتبط بتطوير البرمجيات الموجه باختبار القبول (ATDD)، ولكنه يختلف عنه. ^{[ 16 ]} يُعد TDD في الأساس أداةً للمطورين تُساعدهم على إنشاء وحدات برمجية مكتوبة جيدًا (دالة، أو فئة، أو وحدة نمطية) تُنفذ مجموعة من العمليات بشكل صحيح. أما ATDD فهو أداة تواصل بين العميل والمطور والمختبر لضمان تحديد المتطلبات بدقة. يتطلب TDD أتمتة الاختبارات، بينما لا يتطلبها ATDD، مع أن الأتمتة تُساعد في اختبارات الانحدار . غالبًا ما يُمكن اشتقاق الاختبارات المستخدمة في TDD من اختبارات ATDD، نظرًا لأن وحدات التعليمات البرمجية تُنفذ جزءًا من المتطلبات. يجب أن تكون اختبارات ATDD سهلة القراءة للعميل، بينما لا يُشترط ذلك في اختبارات TDD.

يجمع تطوير البرمجيات الموجه بالسلوك (BDD ) بين ممارسات تطوير البرمجيات الموجه بالاختبار (TDD) وتطوير البرمجيات الموجه بالاختبار القائم على الاختبار (ATDD). ^{[ 17 ]} يتضمن هذا النهج كتابة الاختبارات أولاً، ولكنه يركز على الاختبارات التي تصف السلوك، بدلاً من الاختبارات التي تختبر وحدة تنفيذية. توفر أدوات مثل JBehave و Cucumber و Mspec و Specflow صيغًا تسمح لمالكي المنتجات والمطورين ومهندسي الاختبار بتحديد السلوكيات معًا، والتي يمكن ترجمتها بعد ذلك إلى اختبارات مؤتمتة.

قد يستخدم المطورون أطر اختبار بمساعدة الحاسوب ، والتي تُعرف مجتمعةً باسم xUnit (المشتقة من SUnit، التي أُنشئت عام 1998)، لإنشاء حالات الاختبار وتشغيلها تلقائيًا. توفر أطر xUnit إمكانيات التحقق من صحة الاختبار باستخدام التأكيدات، بالإضافة إلى إمكانية إعداد تقارير النتائج. تُعد هذه الإمكانيات بالغة الأهمية للأتمتة، إذ تنقل عبء التحقق من صحة التنفيذ من عملية معالجة لاحقة مستقلة إلى عملية مُدمجة في تنفيذ الاختبار نفسه. يتيح إطار التنفيذ الذي توفره هذه الأطر إمكانية التنفيذ التلقائي لجميع حالات اختبار النظام أو مجموعات فرعية منها، إلى جانب ميزات أخرى. ^{[ 18 ]}

قد تقبل أطر الاختبار مخرجات اختبار الوحدة في بروتوكول اختبار أي شيء غير المرتبط بلغة معينة والذي تم إنشاؤه في عام 1987.

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

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

تُعدّ نمذجة السيناريوهات تقنيةً أساسيةً لبناء بنية معيارية فعّالة، حيث يتم إنشاء مجموعة من مخططات التسلسل، يركز كل منها على سيناريو تنفيذي واحد على مستوى النظام. يوفر نموذج السيناريوهات أداةً ممتازةً لوضع استراتيجية التفاعلات بين المكونات استجابةً لمحفز محدد. يعمل كل نموذج من نماذج السيناريوهات هذه كمجموعة غنية من المتطلبات للخدمات أو الوظائف التي يجب أن يوفرها المكون، كما يحدد ترتيب تفاعل هذه المكونات والخدمات معًا. يمكن لنمذجة السيناريوهات أن تُسهّل بشكل كبير بناء اختبارات التطوير الموجه بالاختبار (TDD) لنظام معقد. ^{[ 11 ]}

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

يُعد إنشاء وإدارة بنية برمجيات الاختبار ضمن نظام معقد بنفس أهمية بنية المنتج الأساسية. تتفاعل برامج تشغيل الاختبار مع وحدة الاختبار، وبدائل الاختبار ، وإطار عمل اختبار الوحدة. ^{[ 11 ]}

تُتيح منهجية التطوير الموجه بالاختبار (TDD) الحصول على تغذية راجعة سريعة أثناء عملية التطوير، حيث يقوم المطور بتشغيل مجموعة متنامية من الاختبارات الآلية بشكل متكرر. وهذا يُسهّل اكتشاف الأخطاء فور ظهورها، ويدعم إعادة هيكلة الكود من خلال توفير آلية أمان للتغييرات السلوكية. ^{[ 24 ]} ولأن الاختبارات تُكتب قبل كتابة كود الإنتاج، يجب على المطور مراعاة السلوك والواجهة المطلوبين للكود قبل التنفيذ. وهذا يُشجع على استخدام وحدات برمجية أصغر، وترابط أقل ، وواجهات أوضح، خاصةً عند كتابة الاختبارات بناءً على السلوك العام بدلاً من تفاصيل التنفيذ. ^{[ 24 ] [ 21 ]}

يميل تطوير البرمجيات الموجه بالاختبار (TDD) أيضًا إلى إنتاج مجموعة من الاختبارات الآلية كمنتج ثانوي للتطوير. يمكن أن تكون هذه الاختبارات مفيدة في عمليات التكامل المستمر ، حيث تُختبر التغييرات بشكل متكرر قبل دمجها أو إصدارها. وبهذا المعنى، قد يُحسّن TDD الثقة في التغييرات اللاحقة، على الرغم من أن اجتياز اختبارات الوحدة لا يُثبت بحد ذاته صحة البرنامج. ^{[ 19 ] [ 20 ]}

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

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

تُضيف الاختبارات الآلية تكاليف صيانة. فالاختبارات المرتبطة ارتباطًا وثيقًا بتفاصيل التنفيذ الداخلية، أو التي تستخدم محاكاة مفرطة، أو تعتمد على افتراضات توقيت غير دقيقة، أو تحتوي على تعليمات برمجية مكررة، قد يصعب صيانتها. ^{[ 25 ]} في بعض السياقات، لا سيما في المشاريع المعقدة القائمة أو المشاريع ذات الخبرة المحدودة في الاختبارات الآلية، قد يؤدي الوقت اللازم لكتابة الاختبارات وصيانتها إلى انخفاض الإنتاجية على المدى القصير. ^{[ 22 ] [ 20 ]}