TDD، DDD والتغليف
https://stackoverflow.com/questions/1145634
-
16-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
بعد عدة سنوات من اتباع الممارسة السيئة التي سلمت من "المهندسين المعماريين" في مكان عملي والتفكير في أنه يجب أن يكون هناك طريقة أفضل، لقد قرأت مؤخرا حول TDD و DDD وأعتقد أن المبادئ والممارسات ستكون مناسبا رائعا لتعقيد البرنامج الذي نكتبه.
ومع ذلك، فإن العديد من عينات TDD التي رأيتها استدعاء طريقة على كائن المجال ثم اختبار خصائص الكائن لضمان تنفيذ السلوك بشكل صحيح.
من ناحية أخرى، العديد من الأشخاص المحترمين في هذه الصناعة (GREG Young بشكل ملحوظ، بحيث تكون محادثاته حول CQRS) يدعو إلى تغليف كل كائن مجال بالكامل عن طريق إزالة جميع "Getters".
سؤالي هو: كيف اختبار واحد وظيفة كائن مجال إذا كان ممنوع لاسترداد حالته؟
أعتقد أنني أفتقد شيئا أساسيا لذا لا تتردد في الاتصال بي أحمق وتنوير لي - أي إرشادات سيكون موضع تقدير كبير.
المحلول
ما تصفه هو التحقق من الدولة حيث يمكنك التأكيد على حالة كائن المجال. هناك فرع من TDD يسمى التحقق من السلوك التي تستخدم كائنات وهمية.
يسمح لك التحقق من السلوك بتحديد الأساليب التي يجب استدعاؤها وإذا كنت تريد، والتي لا يتم استدعاء الأساليب.
ننظر إلى هذه المقالة من قبل مارتن فاولر لمزيد من التفاصيل: السخرط لا كوذس.
نصائح أخرى
حسنا، هذه الإجابة هي لمدة عام متأخرا جدا ؛-)
ولكن عندما تريد اختبار نماذج CQRS، يمكنك إجراء تأكيدات على أحداث المجال التي أطلقت بدلا من تأكيدات حالة الكيان.
على سبيل المثال إذا كنت ترغب في اختبار ما إذا كان الاتصال: يقوم Customer.rename ("FOO") بنتائج السلوك الصحيح.
بدلا من الاختبار إذا كان العميل. اسما يساوي "Foo"، تفضل الاختبار إذا كان هناك حدث معين في انتظار الحدث مع القيمة "FOO" في متجر الأحداث المعلقة. (في UOW الخاص بك أو في قائمة أحداث كيانك اعتمادا على التنفيذ)
إذا كنت ستذهب حقا إلى حد بعيد لاسترجاع الحالة، فستتقرر في الاختبار السلوكي، وربما من خلال إطار السخرية مثل Typemock، والذي لديه القدرة على تتبع سلوك كائنك. إذا كنت قادرا على القيام BDD نقي، فمن الناحية النظرية، يمكنك تأكيد صحة النظام بالكامل بنفس الطريقة التي تتصرف بها.
في الممارسة العملية، لقد وجدت BDD أن تكون أكثر هشاشة في كثير من الحالات من الاختبار الوحيد. في حين أن بعض الأشخاص قد يدعون نظرية معينة، إلا أنه يعمل فقط إذا كان يعمل من أجلك. لا يزال الاختبار القائم على الدولة يشكل 90٪ من جميع اختبارات الوحدة التي نكتبها، ونحن ندرك جيدا BDD في فريقنا.
هل أفضل ما يمكن عمله بالنسبة لك.
أشياء زوجين.
أولا، عندما تقوم بأشياء مثل TDD لجعل التعليمات البرمجية التي تحقق في نهاية المطاف مع فئة أصغر. إذا كان لديك فئة مع الكثير من الخصائص الخاصة، فلن تتمكن من التفتيش، فهناك فرصة جيدة يمكن تقسيمها إلى فصول متعددة وجعلت أكثر قابلية للاستبدال.
ثانيا، يحاول عمارة OLDSCHOOL OO جعل البرامج آمنة باستخدام ضمانات اللغة لمنع الوصول إلى الأشياء. تقوم بنية TDD بتصنيع البرامج أكثر قوة من خلال اختبارات الكتابة التي تحقق من ما يفعله الرمز فعليا، مما يؤدي إلى التركيز بشكل أقل على استخدام بنيات اللغة لضمان ما لا يفعله البرنامج.
أخيرا، التحقق من خاصية ليست هي الطريقة الوحيدة للتحقق من صحة الرمز فعل ما كان من المفترض أن تفعله. كتاب أنماط تصميم XUNIT TOYSTION نهج أخرى هنا: http://xunitpatterns.com/result٪20verification٪20patterns.html
أدعو أساليب الإدخال العامة للنظام (أي أن أدفع بيانات الإدخال إلى النظام)، ثم أحصل على (وتأكيد) إخراج النظام. أنا لا أختبر حالة النظام الداخلية للنظام، بل سلوكها العام / المرئي: يجب اختبار التنفيذ الداخلي واحد، أو اختبار السلوك العام فقط؟
ما ذكره يسمى اختبار الدولة. هناك أيضا اختبار السلوك. التقنيات المستخدمة لهذا هي حقن التبعية، وعاقل السيطرة، والسخرية:
يتم تطبيق جميع الآثار الجانبية للصفك كغادرات طريقة حول "التبعيات" - أي كائنات مزودة من الخارج، عادة في المنشئ. ثم، في اختبار الوحدة الخاص بك، يمكنك تقديم كائن مزيف بدلا من واحد حقيقي. يمكن أن يتذكر الكائن المزيف إذا تم استدعاء طريقة معينة، وهذا ما تؤكده في الاختبار الخاص بك.
يوجد عدد من أطر السخرية التي تقوم بأتمتة إنشاء كائن وهمية عن طريق إنشاء فصول ديناميكيا التي تنفذ واجهة معينة. الأكثر شعبية هي القرنوقة وموك.
مرحبا يا جاستن، مثلك، كنت أفكر مؤخرا في إضافة Getters إلى كائن المجال الخاص بي فقط من أجل اختبار الوحدة، ولكن الآن أنا مقتنع أنني كنت مخطئا. على افتراض أنك اشتريت في فكرة مجال الكتابة فقط في المقام الأول، إذا كان لديك Getters على الإطلاق، فأنت تطلب مشكلة. يريد منك مبدأ مجال الكتابة فقط بإطلاق حدث من كائن المجال الخاص بك، أو قراءة من الإسقاط الذي كتب كائن المجال الخاص بك، أو شيء من هذا القبيل. بمجرد أن تعرض Getters، فأنت بدأت في ظهور "شكل" الكائن "، كما يقول جريج يونغ،" كائنات المجال لها سلوك وليس شكل ".
التي يقال، أنا تكافح مع سؤالك نفسه ... كيف يمكنك اختبار وحدة كائن مجال الكتابة فقط؟ إليك خطتي الحالية: أفكر في جعل كائنات المجال الخاصة بي إطلاق حدث مجال يقول "هذه الخصائص تغيرت"، وفي اختبار الوحدة الخاص بي، سأقوم بالتسجيل في الأمر قبل أن أرسل "EditCommand". تحقق من مشاركة UDI DAHAN على أحداث المجال هنا, كما ترى أيضا ماذا يقول إريك إيفانز عن أحداث النطاق.
كنت أتساءل نفس الشيء حتى تعثرت أخيرا على الأوراق التالية. لقد وجدت لهم أن يكونوا تعاطيل كبيرين على التحقق من السلوك، وخاصة أول واحد يوفر لي عدة "لحظات آها":
