مقدمة

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

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

الآن بعد أن اقتنعت بالفوائد، يمكنك البدء في التطوير المبني على الاختبار (TDD) باتباع الخطوات التالية:

1. كتابة الاختبارات أو تعديلها
2. التحقق من فشل الاختبار
3. اكتب الحد الأدنى من التعليمات البرمجية لاجتياز الاختبارات

يتم اتباع هذه الخطوات في دورة بحيث تقوم دائمًا بإضافة المزيد من الاختبارات لتحدي التنفيذ الحالي.

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

مثال بسيط

تم تكليفك بتنفيذ الوظيفة Add(x, y int) int. قبل أن تنتقل إلى التنفيذ وتعود إلى x y، اكتب أبسط اختبار: 1 1 == 2. إذن، ما هو أبسط تطبيق يمكنه اجتياز الاختبار؟ إنها مجرد العودة 2. الآن نجحت اختباراتك!

في هذه المرحلة، تدرك أنك بحاجة إلى المزيد من الاختبارات، لذلك يمكنك زيادة السرعة وإضافة المزيد منها:

• 1 2 == 3
• 100 5 == 105

الآن فشلت اختباراتك، لذلك تحتاج إلى إصلاح التنفيذ. لا يمكنك فقط إرجاع 3 أو إرجاع 105 هذه المرة، لذلك تحتاج إلى إيجاد حل مناسب لجميع الاختبارات. وهذا يؤدي إلى التنفيذ: return x y.

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

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

خطوة بخطوة TDD لواجهة برمجة تطبيقات HTTP

دعنا ندخل في مثال أكثر تعقيدًا باستخدام TDD لواجهة برمجة تطبيقات HTTP REST. يستخدم هذا الدليل التفصيلي إطار عمل Go الخاص بي، babyapi، ولكن يمكن تطبيق المفاهيم في أي مكان.

يستخدم babyyapi الأدوية العامة لإنشاء واجهة برمجة تطبيقات CRUD كاملة حول بنيات Go، مما يجعل من السهل جدًا إنشاء واجهة برمجة تطبيقات REST كاملة وواجهة سطر أوامر العميل. بالإضافة إلى ذلك، توفر حزمة babytest بعض الأدوات لإنشاء اختبارات جداول API الشاملة. يتيح استخدام TDD على مستوى واجهة برمجة التطبيقات (API) اختبار HTTP وطبقات التخزين لواجهة برمجة التطبيقات (API) الجديدة أو الميزة الجديدة بالكامل مرة واحدة.

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

1. إنشاء مشروع Go جديد
   

2. قم بإنشاء main.go الأولي باستخدام مثال babyapi البسيط
   

3. استخدم واجهة سطر الأوامر لإنشاء نموذج اختبار
   

4. تنفيذ كل اختبار عن طريق ملء العناصر النائبة بـ JSON المتوقع
   

5. قم بإجراء الاختبارات وتأكد من اجتيازها!

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

7. فشل هذا الاختبار نظرًا لأن babyapi لا يدعم التصحيح افتراضيًا. يمكننا إصلاحه عن طريق تنفيذ التصحيح لبنية TODO. نظرًا لأننا حددنا ميزتنا باختبارين، فإن أبسط تنفيذ لدينا لا يقتصر فقط على إعداد Completed = true وعلينا استخدام القيمة من الطلب
   

8. الآن يمكننا تغيير الحالة المكتملة لـ TODO، ولكننا لا نزال غير قادرين على استخدام التصحيح لتعديل الحقول الأخرى كما تظهر في هذه المجموعة الجديدة من الاختبارات
   

9. تحديث التصحيح لتعيين الحقول المتبقية
   

10. لا تزال اختباراتنا تفشل لأننا نقوم دائمًا بتحديث TODO بحقول الطلب، حتى لو كانت فارغة. قم بإصلاح ذلك عن طريق تحديث التنفيذ للتحقق من القيم الفارغة
    

11. نجح اختبار UpdateWithPatch الجديد، لكن اختباراتنا السابقة فشلت. نظرًا لأننا قمنا بتغيير "مكتمل" إلى *bool، فإن المهام التي تم إنشاؤها بقيمة فارغة ستظهر على أنها فارغة
    

12. تنفيذ Render لـ TODO حتى نتمكن من التعامل مع الصفر على أنه خطأ
    

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

خاتمة

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

إذا كنت مترددًا بشأن اعتماد TDD، فإليك بعض الأفكار للبدء:

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

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