زن من وحدة الاختبار

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

لاول مرة

لماذا يجب أن أكتب اختبارات الوحدة؟

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

ماذا لاختبار؟

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

ميتيلسبيل

اختبار شيء واحد فقط

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

تجنب المنطق

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

ااا

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

التمسك اصطلاح التسمية

يجب أن تكون أسماء الاختبار وصفية ومفهومة ليس فقط لمؤلفها. هناك الكثير من استراتيجيات التسمية التجريبية ، لكني أحب واحدة من استراتيجيات Roy Osherove : [MethodName_StateUnderTest_ExpectedBehavior] . أنه يحتوي على جميع المعلومات اللازمة حول الاختبار بطريقة منسقة. من السهل اتباع هذه الاستراتيجية لأي مطور.

أمثلة:

 public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue () 

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

اختبار إعداد البيانات

بناء بيانات الاختبار يمكن أن يجلب الفوضى والمعاناة إلى رمز الاختبارات الخاص بك. يمكنك مواجهة هذا الموقف عندما:

• يجب عليك تغيير منشئ النموذج الخاص بك في كل جزء من الشفرة حيث يتم إنشاء هذا النموذج (يحدث هذا عادة عندما يكون النموذج الخاص بك غير قابل للتغيير) ؛
• لديك الكثير من التكرارات البرمجية عند إنشاء بيانات الاختبار الخاصة بك ؛
• يجب عليك تمرير الكثير من "البيانات السحرية" إلى مُنشئ النموذج الخاص بك (على سبيل المثال ، new Device("Stub", 10, true, "http"); ) ؛
• لديك شعور أنك تحتاج إلى إنشاء نوع من مولد البيانات العشوائية ؛
• من الصعب عليك إنشاء مجموعات بيانات الاختبارات.

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

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

تعلم إطار الاختبار الخاص بك

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

 Assert.AreEqual(StatusCode.OK, response.StatusCode); 

او

 Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode)); 

لا تنسى عن أساليب الإعداد و teardown وخصائص TestCase والفئة وتأكيدات المجموعة. لا تخلط بين معلمات النتيجة المتوقعة والفعلية في التأكيدات.

نقطة النهاية

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

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

مدونة روي أوشروف
كتاب روي أوشروف ، "فن اختبار الوحدة"

الحفاظ على الهدوء واختبار الوحدة