ما هي التقنيات التي استخدمتها بالفعل بنجاح لتحسين تغطية الكود؟

Question

أحقق بانتظام تغطية بنسبة 100 ٪ للمكتبات باستخدام TDD ، ولكن ليس دائمًا ، ويبدو دائمًا أن هناك أجزاء من التطبيقات التي لم يتم اختبارها وغير مكتشفة.
ثم هناك الحالات التي تبدأ فيها الرمز القديم الذي يحتوي على عدد قليل جدًا من الاختبارات والتغطية القليل جدًا.

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

Answer 1

حذف الرمز.

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

يجب أن أشير إلى أن هذا أكثر قابلية للتطبيق على زيادة تغطية قواعد الكود القديم مقابل قواعد رمز جديدة.

Answer 2

أفترض أنك تقرأ "تم اختبار الرمز مقابل الكود"، حقا ؟

كما ذكر في هذا السؤال ،

حتى مع تغطية كتلة 100 ٪ + تغطية قوس 100 ٪ + 100 ٪ خالية من الأخطاء ، فالرمز المباشر للمسار الواحد ، لا يزال هناك بيانات إدخال تنفذ المسارات/الحلقات بطرق تظهر المزيد من الأخطاء.

الآن ، أنا أستخدم eclemma, استنادًا إلى EMMA وتشرح أداة تغطية التعليمات البرمجية سبب عدم قدرة كود 100 ٪ دائمًا: بسبب خطوط مغطاة جزئيا بسبب:

• فروع ضمنية على نفس الخط.
• رمز المنشئ المشترك.
• الفروع الضمنية بسبب الكتل أخيرًا.
• فروع ضمنية بسبب فئة مخفية. forname ().

لذلك قد تكون جميع هذه الحالات الأربع مرشحين جيدين لإعادة إنشاء تغطية أفضل للرمز.

الآن ، أنا أتفق مع إجابة فرانك كروجر. قد تكون بعض التعليمات البرمجية غير المغطاة أيضًا مؤشراً على بعض إعادة النمو ، بما في ذلك بعض التعليمات البرمجية التي يجب حذفها فعليًا ؛)

Answer 3

كان الأمران اللذان كان لهما أكبر تأثير على المشاريع التي عملت عليها:

1. بشكل دوري "تذكير" فريق التطوير بتنفيذ اختبارات الوحدة الفعلية ، ومراجعة كيفية كتابة اختبارات فعالة.
2. توليد تقرير عن تغطية الاختبار الشاملة ، وتداول ذلك بين مديري التطوير.

Answer 4

نحن نستخدم بيرل ، لذلك Devel :: Cover لقد كان مفيدًا جدًا بالنسبة لنا. يظهر تغطية لكل اختيار وتغطية فرع وتغطية مشروطة أثناء اختبار الوحدة ، وكذلك أشياء مثل تغطية POD. نستخدم إخراج HTML مع الخضر السهل معترف به لـ "100 ٪" ، من خلال الأصفر والأحمر لمستويات تغطية أقل.

تعديل: للتوسع في الأشياء قليلاً:

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

Answer 5

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

الخلفية: لدينا مزيج من القديم والرمز الجديد. نحاول اختبار وحدة/تكامل الأشياء الجديدة قدر الإمكان ، ولكن نظرًا لأننا نتراجع إلى Hibernate/Postgres وبعيدًا عن oodb ، فليس هناك ما لا يتجزأ من اختبار الرمز القديم.

بالنسبة لأولئك الذين لا يعرفون ، فإن FIT هي وسيلة لاختبار البرامج من منظور المستخدم. في الأساس ، يمكنك تحديد السلوك المطلوب في جداول HTML: تحدد الجداول الإجراءات ضد البرنامج والنتائج المطلوبة. يكتب فريقنا "رمز الغراء" (ويعرف أيضًا باسم اختبار FIT) الذي يخطط لإجراءات المكالمات مقابل الكود. لاحظ أن هذه الاختبارات تعمل في عرض "من الفضاء" مقارنة باختبارات الوحدة.

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