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

Question

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

ما هي أفضل طريقة لتنظيم هذه الاختبارات في المكتبة؟ حاليا ، لدي كل الكود في src/ واختباراتي في test/ لكنني قمت بإعداد مشروع ثانوي Flex لتشغيل اختبارات الوحدة. أقوم أيضًا بإضافة ملفات الاختبار وإزالة ملفات الاختبار من المكتبة عندما أرغب في إجراء الاختبارات.

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

Answer 1

الطريقة التي قمنا بها في هذه الأشياء في شركتي هي أننا ندرج بالفعل كلاهما ضمن دليل المصدر ، ثم لدينا ملفان MXML للتطبيقات التي نستخدمها. أحدهما هو جناح الاختبار ، والذي يتضمن جميع الروابط المناسبة لفئات اختبار الوحدة ، والآخر هو التطبيق الرئيسي. لدينا أيضًا هيكلين حزمة داخل مجلد SRC: بنية حزمة واحدة كوم .. ، واختبار آخر ... تأكد من ذلك الكل رمز المصدر لاختبارات الوحدة دائماً في حزمة الاختبارات-وبهذه الطريقة ، يمكنك استخدام SVN واحد فقط ، ويمكنك أيضًا التأكد من أن الاختبارات الخاصة بك لا تخلق علاقات تابعة ومرمدة مع مشاريع أخرى.

هناك طريقتان نستخدمهما للتأكد من عدم تضمين ملفات مصدر Test.com. يشير نظام الإنشاء الآلي فقط إلى التطبيق الرئيسي ، وبما أن الواردات فقط من com. ، سوف يتضمن MXMLC.Exe فقط الملفات للتطبيق الرئيسي. عند البناء محليًا ، داخل Eclipse ، يمكنك التحكم في كيفية بناء الأشياء من خلال النقر على السهم الصغير بجوار التصحيح والتمرير إلى "تنظيم المفضلات". عند النقر فوق "إضافة" ، يجب أن تكون قادرًا على تحديد جميع ملفات .mxml من مستوى الجذر والتي تشير إلى فئة التطبيق. تأكد من إضافة التطبيق الأساسي وملف تطبيق اختبار الوحدة الجديد. عندما تنقر بعد ذلك على "موافق" ، يسمح لك السهم الآن بالتصحيح إما كتطبيق رئيسي ، أو إطار اختبار الوحدة الخاص بك.

جانبا ، نستخدم أيضًا Flexunit كإطار اختبار لدينا. أحبها.

Answer 2

لقد فعلت ذلك مشابهًا للطريقة التي تصفها في الماضي ، لكن يبدو أن هذا النوع من الأشياء Springas يمكن أن تأتي في متناول يديك لإضافة وإزالتها ديناميكيًا من التكوين. هل حاولت النظر في ذلك؟

Answer 3

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

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

Answer 4

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

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

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

3. تعتبر بيئات CI أكثر نظافة لإعدادها عندما لا تكون الاختبارات موجودة.

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

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

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

على أي حال ، هكذا أفعل ذلك.