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

Question

لديّ مطور، يمكنه التغلب على تغطية التعليمات البرمجية الخاصة بنا عن طريق كتابة اختبارات لا تفشل أبدًا.

الكود فظيع للغاية، لكن الاختبارات لا تكتشفه أبدًا لأنها تؤكد (صحيح).

أقوم بمراجعة التعليمات البرمجية، لكن لا يمكنني أن أقوم بالعمل لصالح الجميع طوال الوقت.كيف يمكنك تحفيز أشخاص مثل هؤلاء لصنع برامج جيدة؟

هل هناك مكون إضافي للإنشاء لاكتشاف الاختبارات التي لا يمكن أن تفشل؟

C#، اختبارات mbUnit.

Answer 1

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

ومع ذلك، بافتراض أن مديرك، عقد اجتماع "تعال إلى يسوع" مع المطور.إذا كان هذا لا يزال لا يعمل، هناك دائما الباب.

إذا لم تكن المدير، فقم بإدارة الأمر عبر القنوات المناسبة.

Answer 2

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

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

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

Answer 3

يجب عليك حقًا تحديد اللغة/إطار العمل الذي تستخدمه.

في أبسط الحالات، أعتقد أنه يجب أن يكون من السهل اكتشافه assert(true) سلاسل مع بسيطة grep-بينغ.

Answer 4

يمكنك دائمًا تجربة التشغيل التجريبي باستخدام البيانات المهملة لقيم تكوين التطبيق.

أي الاختبارات التي تمر هي مشبوهة؟

Answer 5

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

• أظهر له كيفية كتابة اختبارات أفضل
• أجبره على إصلاح الكود الخاص به، ومنع تسجيل المزيد من الكود السيئ

سيكون جزء من التعليمات البرمجية التي تجرها الدواب التي يتعين عليك استخدامها بمثابة نقطة بداية جيدة - يجب أن تكون متأكدًا من أنها تعمل...

Answer 6

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

Answer 7

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

يجب عليك إلقاء نظرة على القيام ببعض اختبار الطفرة, ، للكشف عن الاختبارات الضعيفة. نيستر, ، (المعادل الصافي لـ مهرج) هي إحدى الأدوات التي قد تجدها مفيدة.

من فضلك اسمح لنا أن نعرف كيف تسير الأمور!

تحديث:جئت عبر: "لماذا لا يكتب معظم المطورين اختبارات الوحدة حتى الآن؟" واعتقدت أنه سيكون من الجيد القراءة هنا أيضًا.

Answer 8

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

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

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

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

ما هي متطلبات غطاء الرمز الخاص بك؟