يختبر المشاريع في الحل

Question

في .NET هل يجب أن تضع مشاريع اختبار الوحدة مع بقية الحل؟ أو هل يجب أن يكون هناك حل اختبار يضم جميع مشاريع الاختبار؟

لدينا جميع مشاريع الاختبار مع حل قاعدة الكود لدينا ... يبدو مرهقًا بعض الشيء.

ماذا تفعل عادة؟

Answer 1

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

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

وأعتقد أنني يجب أن أشير إلى موضوع مماثل هنا مع المزيد من الإجابات حول نفس الموضوع/مشابه.

Answer 2

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

Answer 3

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

Answer 4

نستخدم دائمًا مشروعًا منفصلًا ضمن نفس الحل.

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

أثناء عملية بناء زر واحد ، نقوم بتشغيل مشروع الاختبار exe. (لدينا فائدة منفصلة لهذا).