هل يتم استخدام السخرية من الكائنات على نطاق واسع؟

Question

أشعر بالفضول لمعرفة عدد الأشخاص الذين يدمجون السخرية من الكائنات (أطر عمل مثل JMock وNMock وRhinoMocks جنبًا إلى جنب مع أطر اختبار الوحدة) في عملية التطوير اليومية.ما هي تجاربك؟

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

Answer 1

في أحد المشاريع التي عملت عليها مؤخرًا، استخدمنا كائنات وهمية على نطاق واسع في نهج اختبار الوحدة الخاص بنا.كان المشروع 100٪ جافا ومتوسط ​​الحجم (حوالي 100000 سطر من التعليمات البرمجية غير المعلقة).لقد كان تطبيق سطح مكتب يستند إلى Swing - وكانت الطريقة الفعالة الوحيدة التي وجدناها لاختبار منطق واجهة المستخدم هي من خلال تصميم متغير MVC الذي سمح لنا باستخدام كائنات وهمية لتحل محل فئات واجهة مستخدم Swing الفعلية للاختبار الآلي.استخدمنا أيضًا السخرية على نطاق واسع في اختبار طبقة الوصول إلى البيانات لدينا (الإسبات/DAOs).

في استخدام واجهة المستخدم، كانت إنشاءات Mocks سهلة ومباشرة.وتم دمج تصميم تطبيق (Fowler Passive View) بسهولة.لم يكن هذا هو الحال بالنسبة للنماذج المستخدمة في اختبار طبقة الوصول إلى البيانات.ولكن يمكنني أن أقول أنه من الواضح أنه كان يستحق كل هذا الجهد.في الواقع، ركزت معظم "الجهود" حقًا على التوصل إلى حل قابل لإعادة الاستخدام يقلل من العمل الذي كان على المطور القيام به لإنشاء كل نسخة وهمية.أوصي بأخذ الوقت الكافي للبحث واكتشاف نهج لموقفك يسمح لك بسهولة محاكاة طبقة بيانات GIS الخاصة بك.هذا - أو مجرد محاكاة كل فئة يدويًا.وفي كلتا الحالتين، فإن القدرة على تشغيل اختبارات الوحدة الآلية التي تعتمد على النماذج جديرة بالاهتمام...

Answer 2

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

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

Answer 3

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

Answer 4

عند محاولة اختبار Sharepoint يبدو أن السخرية هي الطريقة الوحيدة والوحيدة typemock سوف تسمح لك بالسخرية من الفصول المختومة.

Answer 5

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

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

Answer 6

هناك مبادرة بدأها Dave Bouman لمحاولة إنشاء مكتبة مجتمعية من Mocks لاستخدامها في اختبار الوحدات ذات الصلة بـ ArcObjects.تحتوي مدونته ومستودع svn هذا على معلومات رائعة تتعلق بوحدة اختبار أنظمة نظم المعلومات الجغرافية

http://blog.davebouwman.net/CategoryView,category,Unit%2BTesting.aspx

http://svn2.assembla.com/svn/arcdeveloper/TestingUtilities/trunk/