السخرية ليست عكازاً ، السخرية هي مواصفات

هناك العديد من التجاوزات للاختبارات الزوجية ، من بين العديد من المراتب الشاذة التي تدور حول TDDs ، وليس أقلها أسماءها السخيفة.

كانوا يطلقون عليهم بفخر بطريقة أو بأخرى ، وإلا سخروا ، كعب ، مزيف - شعور أننا لا نفقد أي شيء إذا لم نستخدمه. (على عكس "اختبارات التكامل" و "التبعيات الحقيقية").

ومع ذلك ، يمكنك تغيير وجهة النظر. في النهاية ، فإن النموذج الوهمي ليس فقط وليس الكثير يدعم المكون التابع كما يحدد سلوك التبعية. والتنفيذ "الحقيقي" هو تيار معيّن ، وربما تجسيد خاطئ لفكرة فخرنا.

في هذا المعنى ، في كل مرة نكتب

when(mockDependency.method(inputValue)).thenReturn(returnValue) ،

نحن نوثق بعض سلوك المكون.

وبالتالي هناك العديد من العواقب.

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

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

وبالتالي ، تتم إضافة فئات البرامج النصية ValidOrderProviderStub و ExpiredOrderProviderStub و InvalidOrderIdException_OrderProviderStub و OnlyOnceOrderProvider وما إلى ذلك ، والتي يمكن أن تكون في نفس الحزمة وتستخدمها جميع الاختبارات مرة واحدة ، ويتم إضافتها إلى كل فئة من فئات OrderProvider.

يتضمن ذلك فصول تجسس سهلة التنفيذ بنفسك.

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

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

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

إذا كان mok عبارة عن مواصفة ، فهو تسلسل هرمي ويعكس سلوك المكون وفقًا لشروط معينة.

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

وفقًا لذلك ، إذا كان mok عبارة عن مواصفات لسلوك معين ، فإن تنفيذ المكون لا يعدو كونه أكثر من مزامنة سلوك أحد المكونات مع moks الخاصين به.

وربما ، هذه هي الحجة الرئيسية ضد الغوغاء - الحاجة لمزامنة سلوكهم مع التطبيق الفعلي الحالي ، وسوف نتحدث عن هذا بشكل منفصل في المرة القادمة.