إرشادات اختبار الوحدة

Question

هل يعرف أحد مكان العثور على إرشادات وتوصيات اختبار الوحدة؟أرغب في الحصول على شيء يتناول الأنواع التالية من المواضيع (على سبيل المثال):

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

ما الذي لا أسأل عنه والذي يجب أن أكونه؟

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

Answer 1

أوصي كينت بيك كتاب عن TDD.

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

نحن مهتمون جدًا بـ TDD لذا سأجيب على الأسئلة في ضوء ذلك.

هل يجب أن تكون الاختبارات في نفس المشروع مثل منطق التطبيق؟

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

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

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

كيف يمكنني تسمية فئات الاختبار والأساليب والمشاريع الخاصة بي (إذا كانت في مشاريع مختلفة)

أود التأكيد على أن السلوك هو ما يتم اختباره، لذا عادةً ما أقوم بتسمية فئات الاختبار باسم SUT.على سبيل المثال، إذا كان لدي فئة مستخدم، فسوف أقوم بتسمية فئة الاختبار كما يلي:

public class UserBehavior

يجب تسمية الأساليب لوصف السلوك الذي تتوقعه.

public void ShouldBeAbleToSetUserFirstName()

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

هل ينبغي اختبار الأساليب الخاصة والمحمية والداخلية، أم فقط تلك المتاحة للعامة؟

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

هل يجب الفصل بين اختبارات الوحدة والتكامل؟

نعم، يجب عزل اختبارات الوحدة عن اختبارات القبول والتكامل.ينطبق فصل المخاوف على الاختبارات أيضًا.

هل هناك سبب وجيه لعدم الحصول على تغطية اختبار 100%؟

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

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

Answer 2

إنه سؤال جيد.لقد قمنا بتطوير أنفسنا بشكل عضوي، وأظن أن أفضل طريقة هي ذلك.هناك القليل من "الأمر يعتمد على..." هناك.

قمنا بإجراء اختبارات في نفس المشروع، في مساحة اسم فرعية تسمى "UnitTes"

تعكس فئات الاختبار لدينا فئة المنطق، من أجل تبسيط تتبع مكان الاختبارات فيما يتعلق بما يتم اختباره

تتم تسمية الفئات مثل فئة المنطق التي تختبرها، ويتم تسمية الأساليب وفقًا للسيناريو الذي تختبره.

نحن نكتب فقط اختبارات للطرق العامة والداخلية (الاختبار في نفس المشروع)، ونهدف إلى تغطية الفصل الدراسي بنسبة 95%.

أفضّل عدم التمييز بين "الوحدة" و"التفاعل".سيتم قضاء الكثير من الوقت في محاولة معرفة أي منها... حقيبة تلك!الاختبار هو اختبار.

100% من الصعب جدًا تحقيقها طوال الوقت.ونحن نهدف إلى 95٪.هناك أيضًا عوائد متناقصة على مقدار الوقت الذي سيستغرقه الحصول على نسبة الـ 5٪ النهائية وما الذي ستحصل عليه بالفعل.

هذا نحن وما يناسب البيئة والوتيرة.قد تختلف المسافة المقطوعة.فكر في بيئتك والشخصيات المعنية.

وإنني أتطلع إلى رؤية ما يقوله الآخرون حول هذا الموضوع!

Answer 3

إجابة جوش صحيحة - مجرد نقطة واحدة للتوضيح:

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

لا تعبر الحزم.سوف تحدث أشياء سيئة إذا قمت بذلك.

Answer 4

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

Answer 5

فيما يتعلق بسؤالك الأخير، من خلال تجربتي، فإن السبب "الجيد" لعدم الإصرار على تغطية الاختبار بنسبة 100% هو أن الأمر يتطلب قدرًا غير متناسب من الجهد للحصول على النقاط المئوية القليلة الأخيرة، خاصة في قواعد الأكواد الأكبر حجمًا.على هذا النحو، يتعلق الأمر بتحديد ما إذا كان الأمر يستحق وقتك أم لا بمجرد وصولك إلى نقطة تناقص العوائد.

Answer 6

مرتب:

• لا، من الأفضل عادةً تضمينها في مشروع منفصل؛إلا إذا كنت تريد أن تكون قادرًا على تشغيل التشخيصات في وقت التشغيل.
• والمثالي هو تغطية التعليمات البرمجية بنسبة 100%، وهو ما يعني كل سطر من التعليمات البرمجية في كل روتين في كل فصل دراسي.
• أذهب مع ClassnameTest، ClassnameTest.MethodNameTestnumber
• كل شئ.
• أود أن أقول نعم، حيث لا يلزم إجراء اختبارات التكامل في حالة فشل اختبارات الوحدة.
• الخصائص البسيطة التي تم تعيينها للتو والحصول على حقل لا تحتاج إلى اختبارها.

Answer 7

هل يجب أن تكون الاختبارات في نفس المشروع مثل منطق التطبيق؟

هذا يعتمد.هناك مقايضات في كلتا الحالتين.

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

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

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

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

لا.

يجب أن يكون لديك فصول اختبار تسمح لكود اختبار جيد العوامل (على سبيل المثال.الحد الأدنى من الازدواجية والنية الواضحة وما إلى ذلك).

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

كيف يمكنني تسمية فئات الاختبار والأساليب والمشاريع الخاصة بي (إذا كانت في مشاريع مختلفة)

يجب عليك تسميتها بحيث:

• كل فئة اختبار وطريقة اختبار لها غرض واضح
• حتى يتمكن من يبحث عن اختبار معين (أو عن اختبارات حول وحدة معينة) من العثور عليه بسهولة.

هل ينبغي اختبار الأساليب الخاصة والمحمية والداخلية، أم فقط تلك المتاحة للعامة؟

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

هل يجب الفصل بين اختبارات الوحدة والتكامل؟

يعتمد هذا على اختيارك لإطار (إطارات) الاختبار.افعل ما هو أفضل مع إطار (إطارات) الاختبار الخاص بك واجعله بحيث:

• من السهل العثور على كل من اختبارات الوحدة والتكامل المتعلقة بجزء من التعليمات البرمجية،
• من السهل إجراء اختبارات الوحدة فقط،
• من السهل إجراء اختبارات التكامل فقط،
• من السهل إجراء جميع الاختبارات.

هل هناك سبب وجيه لعدم الحصول على تغطية اختبار 100%؟

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

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

بدلاً من القاعدة البسيطة التي تنص على أنه يجب أن يكون لديك تغطية خطية بنسبة 100%، شجع المطورين لديك على اكتشافها أي الفجوات في الاختبار الخاص بك، وإيجاد طرق لإصلاح تلك الفجوات، سواء تم تحسين عدد الأسطر "المغطاة" أم لا.بمعنى آخر، إذا قمت بقياس الخطوط المغطاة، فسوف تقوم بتحسين تغطية الخط الخاص بك - ولكن ما تريده بالفعل هو تحسين الجودة.لذلك لا تنس أن تغطية الخط هي مجرد تقدير تقريبي للجودة.