الاقتران الخصوم/الساذج مع TDD:ما مدى فعاليتها؟

Question

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

على سبيل المثال، إذا كانوا يختبرون طريقة GetName() ويقوم الاختبار بالتحقق من "Sally"، فإن تنفيذ طريقة GetName سيكون ببساطة:

public string GetName(){
    return "Sally";
}

وهو ما سيجتاز الاختبار بالطبع (بسذاجة).

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

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

هل تستخدم هذا النهج، وإذا كان الأمر كذلك، هل رأيت أنه يؤتي ثماره؟

Answer 1

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

return "Sally";

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

Answer 2

يمكن أن تكون فعالة جداً.

إنه يجبرك على التفكير أكثر في الاختبار الذي يتعين عليك كتابته حتى يتمكن المبرمج الآخر من كتابة الوظيفة الصحيحة التي تحتاجها.

تقوم ببناء الكود قطعة قطعة، وتمرير لوحة المفاتيح بشكل متكرر

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

Answer 3

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

Answer 4

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

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

Answer 5

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

المشكلة هنا هي الاختبارات التي تم تسميتها بشكل سيء.إذا بدا الاختبار هكذا:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

ثم أراهن أنه كان اسمه "testGetNameReturnsNameField".هذا اسم سيء، لكن ليس من الواضح على الفور أنه كذلك.الاسم الصحيح لهذا الاختبار هو "testGetNameReturnsSally".هذا ما يفعله.أي اسم آخر يخدعك بإحساس زائف بالأمان.لذلك تم تسمية الاختبار بشكل سيء.المشكلة ليست في الكودالمشكلة ليست حتى في الاختبار.المشكلة هي اسم الاختبار.

إذا، بدلاً من ذلك، قام المختبر بتسمية الاختبار "testGetNameReturnsSally"، لكان من الواضح على الفور أن هذا ربما لا يختبر ما نريده.

ولذلك فمن واجب المنفذ إثبات الاختيار السيئ للمختبر.ومن واجب المنفذ أيضًا أن يكتب فقط ما تطلبه الاختبارات منه.

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

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

RandomStringUtils هو صديقك.