على مدى الأشهر العشرة الماضية ، عمل المطورون في edX بجد لزيادة تغطية الاختبار الآلي. تغطي اختبارات وحدة Python البالغ عددها 10 حاليًا 2,491٪ من الخطوط في repo منصة edx. تعمل هذه الاختبارات ، جنبًا إلى جنب مع اختبارات قبول السيلينيوم واختبارات وحدة جافا سكريبت ، على كل طلب سحب ، مما يسمح لنا بالتحقق بسرعة من صحة تغييرات الكود المقترحة.
كيف قمنا بزيادة تغطية الاختبار من أقل من 50٪ إلى 87٪ في 10 أشهر فقط؟ جزء من الجواب هو أداة تسمى فرق الغلاف.
في سير عمل نموذجي ، قد يقوم مطور يعمل في مشروع كبير بتقديم طلب سحب يغير بضع عشرات من سطور التعليمات البرمجية. قبل التغيير ، قد تكون تغطية الاختبار 72٪ ؛ بعد ذلك ، يمكن أن تظل 72٪. حجم المشروع يجعل من الصعب رؤية تأثير طلب سحب واحد. يتيح لك Diff-cover التركيز على مقاييس الجودة لطلب سحب واحد بدلاً من المشروع ككل.
غطاء التباين يقيس سطور التعليمات البرمجية في بوابة فرق. بالنسبة للتغيير المقترح للرمز ، سيُظهر لك أي من الأسطر التي تم تغييرها يفتقد إلى التغطية. هذه فكرة بسيطة ، لكن لها آثار قوية:
- بالنسبة للمطورين ، يوفر غطاء الاختلاف مقياسًا واضحًا وقابل للتحقيق: إذا لمست سطرًا من التعليمات البرمجية ، فيجب تغطيته.
- بالنسبة لمراجعي الكود ، فإن غطاء الاختلاف يجعل من السهل التحقق من قيام المطورين بكتابة الاختبارات لجميع تغييرات التعليمات البرمجية.
من خلال التركيز على تغطية الفروق ، يمكن للمطورين اتخاذ خطوات صغيرة ومرئية نحو تحسين التغطية العالمية. قد يزيد التزام معين شامل تغطية بنسبة ضئيلة من نسبة مئوية ولكن لا يزال لديها 95٪ فرق تغطية. ببطء ولكن بثبات ، مع قيام المطورين بكتابة اختبارات لتغييرات التعليمات البرمجية ، بدأت التغطية العالمية في الزيادة أيضًا. نتيجة لذلك ، تمكنا من التقاط أنواع معينة من الحشرات في وقت أقرب.
والأهم من ذلك ، بدأ المطورون الآخرون في المساهمة في تغطية نفسها والحصول على ملكية الأداة. على سبيل المثال ، عمم كال الأداة لدعم فحوصات "الجودة" الإضافية ، ووسعتها سارينا للإبلاغ عن انتهاكات pep8 و Pylint في فرق. قدم العديد من المطورين الآخرين ملاحظات واقتراحات خلال اختبار تجريبي أولي للغطاء الفردي. أصبحت الأداة نقطة انطلاق لإعادة فحص معايير مراجعة واختبار الكود ، مما أدى إلى تغيير حقيقي في ثقافة الاختبار لدينا.
بالطبع ، لا يزال قياس التغطية به بعض القيود المهمة. على وجه الخصوص ، تغطية فرق عالية تفعل لست ضمان رمز خالٍ من الأخطاء: في نظام متقارب بإحكام ، قد يكون للتغيير في أحد المكونات عواقب بعيدة المدى وغير مقصودة على أجزاء أخرى من النظام - حتى لو تم تغطية الرمز الذي تم تغييره بنسبة 100٪. في مثل هذه الحالات ، يمكن لاختبارات التكامل اكتشاف الأخطاء التي قد تفوتها اختبارات الوحدة.
إذا كنت تعتقد أن diff-cover قد يكون مفيدًا لك ، فتحقق من المشروع - إنه مفتوح المصدر و متاح على جيثب. تم تصميم الكود ليكون قابلاً للتوسيع لأنظمة التحكم في الإصدارات الأخرى ومدققات الجودة ، لذلك لا تتردد في إضافة ميزات وتقديم طلب سحب!
ويل دالي مهندس اختبار في edX. عندما لا يدعو إلى التطوير القائم على الاختبار أو تحسين مجموعة جنكينز ، فإنه يستمتع بالركض على طول الأنهار وتقليل عدد الأشياء في شقته.
