حروب التنمية مدفوعة الاختبار: ديترويت ضد لندن ، كلاسيك ضد موكست

أتذكر عندما بدأت تعلم البرنامج لأول مرة ، وشرح لي أحد أساتذتي عالم تطوير البرامج في جملة واحدة:

"إنها مجرد حفنة من الناس في غرفة يتجادلون مع بعضهم البعض"

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

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

ولكن ما هو كلاسيكي وما هو Mockist؟

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

ربما تكون قد سمعت بممارسي Classicist TDD المشهورين بما في ذلك العم بوب وكينت بيك. إذا كنت تريد مثالاً على Mockist ، فلا تنظر إلى Sandi Metz أو J.B Rainsberger أو Steve Freeman.

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

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

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

def calculate_total_balance (x، y)
 # منطق العمل المعقد الذي يحول x و y
 some_calculator_object.sum (س، ص)
النهاية

سيختبر الكلاسيكيين هذا عن طريق التأكيد على طريقة calculate_total_balance وعلى افتراض أن كل من x و y هما 2 و 5 ، فإن الاختبار النهائي يتوقع قيمة 7. وبالتالي فإن مدرسة Detroit لا تخاف من اختبار المتعاونين مع مثيل بشكل غير مباشر من خلال واجهة فئة أخرى. لن يتم تقديم أي يسخر هنا.

إذا كان أحد ممارسي مدرسة لندن يختبر هذه الطريقة الفردية ، فلن يكون التوقع هو 7 ، ولكن سيكون لدينا شيء من هذا القبيل

توقع (any_instance_of (الحاسبة)). الحصول على (: sum). (2،5)

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

سيصر Classicists على أن نهج Mockist لا يفعل شيئًا لتأكيد حالة عمل التطبيق ، كما يربط الاختبارات بالتنفيذ. إذا قمنا بتغيير أسلوبنا أعلاه لاستخدام ، على سبيل المثال ، خدمة الحاسبة ، فسيبقى السلوك كما هو وسيظل لدينا الرقم 7 ، لكن اختبارنا سيؤدي الآن إلى إصدار إنذار خاطئ على الرغم من أن كل شيء يعمل بشكل جيد.

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

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

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

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

يفضل Mockists اختبار المربع الأبيض بالقول: أطلب طريقة ، ولا أهتم بالصحة العامة للطريقة لأن هذا يتصل بكائن آخر سأختبر قيمة الإرجاع في مكان آخر. كل ما يهمني هو أنه يتواصل بشكل فعال.

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

إذا أردنا تصنيف اختبارات مفيدة وذات قيمة عالية يمكن أن تقدم قيمة أعمال حقيقية ، فسوف أقوم بإجراء اختبارات فعالة:

  1. لديك فرصة كبيرة لاصطياد الانحدارات
  2. لديك فرصة منخفضة لإنتاج ايجابيات كاذبة
  3. تقديم ملاحظات سريعة

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

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