C# - باستثناء اختبارات الوحدة من نسخة إصدار مشروعك

https://stackoverflow.com/questions/81784

09-06-2019
|

سؤال

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

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

أحد الحلول التي وجدتها هو تضمين جميع اختبارات الوحدة الخاصة بك ضمن توجيهات #if DEBUG -- #endif:عندما لا يشير أي كود إلى مجموعة اختبار الوحدة، يكون المترجم ذكيًا بما يكفي لحذف المرجع في الكود المترجم.

هل هناك أي خيارات أخرى (ربما أكثر راحة) لتحقيق هدف مماثل؟

المحلول

أنا بالتأكيد أؤيد فصل اختباراتك إلى مشروع منفصل.إنها الطريقة الوحيدة للذهاب في رأيي.

نعم كما غاري كما يقول، فإنه يجبرك أيضًا على اختبار السلوك من خلال الأساليب العامة بدلاً من اللعب بأجزاء فصولك الداخلية

نصائح أخرى

وكما أشار الآخرون، يعد مشروع الاختبار المنفصل (لكل مشروع عادي) طريقة جيدة للقيام بذلك.أقوم عادةً بعكس مساحات الأسماء وإنشاء فئة اختبار لكل فئة عادية مع إلحاق كلمة "اختبار" بالاسم.يتم دعم هذا مباشرة في IDE إذا كان لديك Visual Studio Team System والذي يمكنه إنشاء فئات وأساليب اختبار تلقائيًا في مشروع آخر.

شيء واحد يجب أن تتذكره إذا كنت تريد اختبار الفئات والأساليب باستخدام الملحق "الداخلي" هو إضافة السطر التالي إلى ملف AssemblyInfo.cs لكل مشروع سيتم اختباره:

[assembly: InternalsVisibleTo("UnitTestProjectName")]

يحتوي إطار عمل .Net بعد الإصدار الثاني على ميزة مفيدة حيث يمكنك وضع علامة على التجميع باستخدام سمة InternalsVisibleTo التي تسمح للآخرين بالوصول إلى التجميع.
نوع من ميزة نفق التجميع.

هناك بديل آخر لاستخدام توجيهات المترجم داخل ملف أو إنشاء مشروع منفصل وهو مجرد إنشاء ملفات .cs إضافية في مشروعك.

مع بعض السحر في ملف المشروع نفسه، يمكنك إملاء ما يلي:

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

مثال مقتطف .csproj:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

   ...

   <Reference Include="nunit.framework" Condition=" '$(Configuration)'=='Debug' ">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\debug\nunit.framework.dll</HintPath>
   </Reference>

   ...

   <Compile Include="Test\ClassTest.cs" Condition=" '$(Configuration)'=='Debug' " />

   ...
</Project>

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

الحفاظ على مساحات الأسماء المتوازية واستخدام اصطلاح تسمية معقول للاختبارات (على سبيل المثال.سيساعدك MyClass وMyClassTest) في الحفاظ على قاعدة التعليمات البرمجية قابلة للصيانة.

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

الجزء المعقد، بالطبع، هو عندما يكون لدى الشركة 55 مشروعًا في الحل و60% منها عبارة عن اختبارات.عد نفسك محظوظا.

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

يوجد لكل مشروع مشروع اختباري مطابق يحتوي على اختبارات عليه.

على سبيل المثالبالنسبة للتجميع المسمى، على سبيل المثال "Acme.BillingSystem.Utils"، سيكون هناك تجميع اختبار يسمى "Acme.BillingSystem.Utils.Test".

قم باستبعاده من إصدار الشحن لمنتجك عن طريق عدم شحن ملف dll هذا.

لقد احتفظ دائمًا باختبارات الوحدة الخاصة بي في مشروع منفصل حتى يتم تجميعها في التجميع الخاص بها.

شيء واحد لم يتم أخذه في الاعتبار بعد هو أن إصدارات VisualStudio قبل عام 2005 لم تسمح بالرجوع إلى مشاريع تجميع EXE من مشاريع أخرى.لذا، إذا كنت تعمل على مشروع قديم في VS.NET، فإن خياراتك ستكون:

ضع اختبارات الوحدة في نفس المشروع واستخدم التجميع الشرطي لاستبعادها من إصدارات الإصدار.
انقل كل شيء إلى تجميعات dll بحيث يكون ملف exe الخاص بك مجرد نقطة دخول.
التحايل على IDE عن طريق اختراق ملف المشروع في محرر النصوص.

من بين التجميعات الشرطية الثلاثة هو الأقل عرضة للخطأ.

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

#if TEST
#endif

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

أقوم دائمًا بإنشاء مشروع Acme.Stuff.Test منفصل يتم تجميعه بشكل منفصل.

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

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

إذا #إذا (التصحيح) تسمح العلامة بإصدار "إصدار" نظيف، فلماذا تحتاج إلى مشروع منفصل للاختبارات.مثال الوحدة LibarryA/B (نعم، أعرف أنه مثال) يفعل ذلك.يتصارع حاليا مع السيناريو.تم استخدام مشروع منفصل، ولكن يبدو أن هذا قد يسمح ببعض التحسينات في الإنتاجية.لا يزال هومين وهوين.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow