كيفية تخفيف TDD باستخدام MSTest / VS2008

Question

لقد قرأت مرارًا وتكرارًا أن TDD/test أولاً أكثر صعوبة مع MSTest مما هو عليه مع أطر الاختبار الأخرى مثل nUnit وMBUnit وما إلى ذلك...ما هي بعض الحلول اليدوية المقترحة و/أو وحدات البت التابعة لجهات خارجية والتي تقترحها عندما يكون MSTest هو الخيار الوحيد بسبب سياسة البنية التحتية؟أتساءل بشكل أساسي عن VS 2008 Team Suite، لكنني أفترض أن النصائح الخاصة بـ VS 2008 Pro الأحدث ستكون مناسبة أيضًا نظرًا لأن بعض وظائف MSTest مضمنة الآن في هذه الإصدارات أيضًا.

Answer 1

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

• الاختصارات.كما قال Haacked، خذ بضع ثوان لتتعلم الاختصارات.
• السياق الحالي.نظرًا لأن MSTest بطيء جدًا، قم بإجراء الاختبارات فقط في السياق الحالي عندما تستطيع ذلك.(كنترول+ر, كنترول+ت).إذا كان المؤشر في طريقة اختبار، فسيؤدي ذلك إلى تشغيل الطريقة فقط.إذا كان المؤشر خارج الطريقة، ولكن في فئة اختبار، فسيؤدي ذلك إلى تشغيل الاختبار فقط.ومع مساحة الاسم، الخ الخ
• اختبارات وتنظيم فعال.إنه كلب بطيء.اجعل الأمور بأفضل ما يمكنك عن طريق كتابة اختبارات فعالة.انقل الاختبارات البطيئة إلى فئات أو مشاريع اختبار أخرى حتى تتمكن من إجراء الاختبارات السريعة بشكل متكرر.
• اختبار مع WCF.إذا كنت تختبر الخدمات، فتأكد من إجراء اختبارات DEBUG بدلاً من اختبارات RUN حتى يتمكن Visual Studio من تشغيل خوادم الويب الخاصة بتطوير ASP.NET.بعد الانتهاء من ذلك، يمكنك العودة إلى RUN، ولكن قد يكون من الأسهل إجراء التصحيح دائمًا حتى لا تضطر إلى التفكير في الأمر.
• ملفات التكوين.قم بتحرير تكوين التشغيل الاختباري لنقل ملفات .config إلى مجلد تنفيذ الاختبار.
• التكامل مع المصدر الآمن.عليك أن تدرك أن MSTest يكره SourceSafe وأن الشعور متبادل.نظرًا لأن MSTest يريد وضع ملفات الاختبار تحت التحكم بالمصادر، وإضافتها إلى الحل، فيجب عليه التحقق من الحل في كل مرة تقوم فيها بتشغيل الاختبارات.لذلك يجب تشغيل SourceSafe في وضع السحب المتعدد لتجنب قتل زملائك من المطورين.
• تجاهل الزغب مع MSTest، يمكنك الحصول على عشرات النوافذ وطرق العرض المختلفة.عمليات التشغيل الاختبارية وعرض الاختبار وقوائم الاختبار ...كلهم أقل فائدة.التزم بنتائج الاختبار وستكون أكثر سعادة.
• التزم بـ "اختبارات الوحدة".عند إضافة اختبار جديد، يمكنك إضافة اختبار مرتب، أو اختبار وحدة، أو تشغيله من خلال المعالج.التزم باختبارات الوحدة البسيطة فقط.

Answer 2

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

الاختبار في السياق الحالي: كنترول+ر, ت
جميع الاختبارات في الحل: كنترول+ر, أ

اختبارات التصحيح في السياق الحالي: كنترول+ر, كنترول+ت
تصحيح كافة الاختبارات في الحل: كنترول+ر, كنترول+أ

Answer 3

أنا فضولي هنا.ما لا أفهمه هو أن الأشخاص يبدأون في مقارنة جميع الأدوات مفتوحة المصدر المتوفرة مع MSTest ويبدأون في مهاجمتها.التعليق على مدى صعوبة الأمر، ومدى عدم بديهته، وما إلى ذلك.IMHO، هذا لأنه يختلف اختلافًا جوهريًا عن أطر عمل xUnit.إنه مُحسّن للتنفيذ المتوازي.

حتى صعوبة وجود ClassInitialze و Cleanup الثابت والحصول على TestContext فريد لكل اختبار، كل ذلك بسبب الجيل التالي - على الأقل بالنسبة لمبرمجي أعمال Windows بلغات MS - مفاهيم البرمجة المتوازية.

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

Answer 4

لدى زميلي مايك هادلو ملخصًا جيدًا عن سبب كرهنا التام لـ MSTest هنا.

لقد تمكن من إزالته من مشروعه، لكنني أعمل حاليًا على مشروع أكبر يتضمن المزيد من السياسة، لذلك ما زلنا نستخدمه.

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

Answer 5

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

Answer 6

هناك الكثير من ملفات التكوين مع mstest، مما يجعلها أقل فضولا.
السبب الآخر الذي جعلني أختار mbunit هو ميزة "التراجع" في mbunit.يتيح لك هذا التراجع عن جميع أشياء قاعدة البيانات التي تم إجراؤها في هذا الاختبار، حتى تتمكن بالفعل من إجراء اختبارات الدائرة الكاملة ولا تقلق بشأن تلوث البركة بعد الاختبار.
أيضًا عدم وجود مرافق RowTest في mstest.

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

Answer 7

• يحتوي MSTest على "احتكاك عالي":الحصول على نص بناء مع Naant و Mbunit مقارنة مع MSTEST و MSBUILD.لا مقارنة.
• MSTEST بطيئة mbunit و nunit في خبرتي بشكل أسرع (قد يساعد جاليو هنا)
• يضيف MSTEST مجموعة من الأشياء التي لا أحتاجها مثل ملفات التكوين السلكية وما إلى ذلك.
• لا يحتوي MSTest على مجموعة الميزات الخاصة بأطر اختبار نظام التشغيل الأخرى.تحقق من xUnit وMbUnit

إنه صعب الاستخدام للغاية وهناك العديد من الخيارات الأفضل.

Answer 8

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

أيضًا، MSTest بطيء جدًا، وذلك لأنه بين كل اختبار يعيد بناء السياق بأكمله لكل اختبار، وهذا يجعلنا متأكدين من أن الاختبار السابق - فشل أو لا يؤثر على الاختبار الحالي، ولكنه يبطئ الأمور.ومع ذلك، يمكنك استخدام علامة /noisolation، التي ستقوم بتشغيل جميع الاختبارات ضمن عملية MSTest - وهي أسرع.لتسريع في IDE:في VS ide، يمكنك الانتقال إلى Tools-Options ثم تحديد Test Tools.حدد عنصرًا فرعيًا يسمى تنفيذ الاختبار وفي الحوار الموجود على اليمين تأكد من تحديد خانة الاختيار المسماة "الاحتفاظ بمحرك تنفيذ الاختبار قيد التشغيل بين عمليات التشغيل الاختبارية".

Answer 9

للإجابة على سؤال غير مدعوم ، ستكون إجابتي "ربما تظل نونيت خارج وجهك".

تنصل:ليس لدي أي خبرة فعلية مع إصدار MS من xUnit، ومع ذلك أسمع مشكلات مثل "تحتاج إلى تثبيت الفكرة العملاقة فقط لتشغيل اختباراتك على جهاز منفصل" - وهو رفض كامل.بخلاف ذلك، لدى MS هذه الطريقة لتحريف المسار الصحيح للمبتدئ عبر نوع من جرس/صافرة IDE الذي يتعارض مع الفكرة بأكملها.مثل إنشاء اختبارات من الفصول الدراسية كان الأمر الذي أتذكره منذ عام أو نحو ذلك ..الذي يهزم بيت القصيد من اختبار القيادة - من المفترض أن ينشأ تصميمك من خطوات صغيرة من RGR:كتابة اختبار-جعله اجتياز إعادة البناء.إذا كنت تستخدم هذه الأداة - فإنها تحرمك من التجربة بأكملها.

سأتوقف عن خطبتي..الآن :)

Answer 10

لقد قمت بتطوير TDD باستخدام NUnit لعدد من السنوات وأستخدم MSTest منذ حوالي 4 أشهر بسبب تغيير الدور.

لا أعتقد أن MSTest يمنع أي شخص من القيام بـ TDD.لا يزال لديك كل الأشياء الأساسية التي تحتاجها لـ TDD مثل التأكيدات الأساسية وأطر العمل الساخرة (أستخدم Rhino Mocks).

يتكامل MSTest بشكل وثيق مع Visual Studio، وأفضل مكون لهذا التكامل هو أداة تغطية التعليمات البرمجية المضمنة.

ولكن هناك عدد من الأسباب المقنعة لا لاستخدام MSTest.أكبر عطلين في رأيي هما:

1. عدم وجود خيارات التأكيد (مقارنة بـ NUnit)
2. عداء الاختبار البطيء (بطيء مقارنة بـ NUnit)

هذا يعني أن كتابة التأكيدات تتطلب المزيد من التعليمات البرمجية مع عداء اختبار بطيء مما يعني أن العملية برمتها أبطأ من NUnit.تتمتع الخيارات مفتوحة المصدر أيضًا بمزيد من الدعم في المجتمع.

إذا كنت تستخدم TFS for CI، فستحتاج إلى تجاوز بعض الخطوات/الاختراقات حتى تتمكن NUnit من نشر نتائج الاختبار.يعد إجراء الاختبارات على TFS مع MSTest بالمقارنة أمرًا سهلاً للغاية ومباشرًا.إذا لم تلمس TFS فسأذهب إلى NUnit على طول الطريق، إنه أفضل.