ملفات بناء اختبار الوحدة

Question

ما هي أفضل السياسات لملفات بناء اختبار الوحدة؟

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

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

لابد من وجود طريقة أفضل.أفكار؟

Answer 1

هذا هو النهج الذي اتبعناه عند إنشاء قاعدة تعليمات برمجية كبيرة (عدة ملايين من أسطر التعليمات البرمجية) عبر أكثر من اثنتي عشرة منصة.

• تتم مراجعة تغييرات Makefile بواسطة فريق الإنشاء. يعرف هؤلاء الأشخاص الأخطاء التي يميل الأشخاص إلى ارتكابها في بيئة البناء الخاصة بنا، وهم الذين يشعرون بالعبء الأكبر منها عندما يتعطل البناء، لذلك يتم تحفيزهم للعثور على المشكلات.
• قم بتقليل ما يجب إدخاله في ملف Makefile, ، لذلك هناك فرص أقل للخطأ.لدينا طبقة أعلى النموذج، والتي تولد ملف Makefile.يجب على المطور فقط أن يشير في الملف ذي المستوى الأعلى، باستخدام العلامات، إلى أن الهدف المحدد، على سبيل المثال، هو مكتبة مشتركة أو اختبار وحدة.عادةً ما يتم تعريف الهدف في سطر واحد، مما يؤدي بعد ذلك إلى إعدادات/أهداف متعددة في ملف Makefile الذي تم إنشاؤه.يمكن القيام بأشياء مماثلة باستخدام أدوات البناء مثل السكونز التي تسمح للمرء باستخلاص أشياء مثل التفاصيل الخاصة بالمنصة، مما يجعل الأهداف بسيطة للغاية.
• اختبارات الوحدة لأداة البناء الخاصة بنا. الأداة مكتوبة بلغة Perl، لذلك نستخدم لغة Perl اختبار::المزيد إطار عمل اختبار الوحدة هناك للتحقق من أن الأداة تنشئ ملف Makefile الصحيح نظرًا لملفنا ذي المستوى الأعلى.إذا استخدمنا شيئًا مثل scons بدلاً من ذلك، سأستخدمه إطار الاختبار الخاص بهم.
• اختبارات الوحدة لنصوص البناء/الاختبار الليلية الخاصة بنا. لدينا مجموعة من البرامج النصية التي تبدأ عمليات البناء ليلاً على كل منصة، وتقوم بتشغيل أدوات التحليل الثابتة، وتشغيل اختبارات الوحدة، وتشغيل الاختبارات الوظيفية، وإبلاغ جميع النتائج إلى قاعدة بيانات مركزية.نقوم باختبار البرامج النصية المختلفة بشكل فردي، وغالبًا ما نستخدم ملف شونيت2 إطار اختبار الوحدة لـ sh/bash/ksh/etc.
• اختبارات شاملة لعملية البناء/الاختبار لدينا. أنا أعمل على اختبار شامل يعمل على شجرة مصدر صغيرة بدلاً من كود الإنتاج الخاص بنا، نظرًا لأن الأخير يمكن أن يستغرق ساعات من الإنشاء.تهدف هذه الاختبارات بشكل أساسي إلى التحقق من أن أهداف البناء الخاصة بنا لا تزال تعمل وإبلاغ النتائج إلى قاعدة البيانات المركزية لدينا حتى بعد، على سبيل المثال، ترقية أداة تغطية التعليمات البرمجية لدينا أو إجراء تغييرات على البرامج النصية للبناء لدينا.

Answer 2

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

Answer 3

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