ما هي بعض اصطلاحات التسمية الشائعة لاختبارات الوحدة؟[مغلق]

Question

عام

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

أمثلة

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

مصدر: معايير التسمية لاختبارات الوحدة

2) فصل كل كلمة عن طريق الشرطة السفلية

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

آخر

• نهاية أسماء الطرق بـ امتحان
• ابدأ أسماء الطرق باسم الفئة

Answer 1

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

• واضح حول ماهية كل حالة اختبار.
• محددة حول السلوك المتوقع.

ما الذي تحتاجه أكثر من اسم الاختبار؟

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

أما بالنسبة لطول واستخدام الشرطة السفلية، فهو رمز الاختبار, ، من يهتم بحق الجحيم؟لن يتمكن أحد سواك أنت وفريقك من رؤيته، طالما أنه قابل للقراءة وواضح بشأن ما يفعله الاختبار، استمر!:)

ومع ذلك، ما زلت جديدًا تمامًا في الاختبار و تدوين مغامراتي معها :)

Answer 2

وهذا أيضًا يستحق القراءة: اختبارات الوحدة الهيكلية

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

على سبيل المثال

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

وهنا السبب:

حسنًا، لسبب واحد، إنها طريقة رائعة للحفاظ على تنظيم الاختبارات.كل ال يتم تجميع الاختبارات (أو الحقائق) لطريقة ما معا.على سبيل المثال ، إذا يمكنك استخدام اختصار CTRL + M و CTRL + O لطي أجسام الأسلوب ، يمكنك امسح اختباراتك ضوئيا بسهولة واقرأها كمواصفات للكود الخاص بك.

أنا أيضا أحب هذا النهج:

MethodName_StateUnderTest_ExpectedBehavior

لذلك ربما التكيف مع:

StateUnderTest_ExpectedBehavior

لأن كل اختبار سيكون بالفعل في فئة متداخلة

Answer 3

أنا أميل إلى استخدام اتفاقية MethodName_DoesWhat_WhenTheseConditions لذلك على سبيل المثال:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

ومع ذلك، ما أراه كثيرًا هو جعل اسم الاختبار يتبع بنية اختبار الوحدة

• يرتب
• يمثل
• يجزم

والذي يتبع أيضًا بناء جملة BDD/Gherkin لـ:

• منح
• متى
• ثم

والذي سيكون تسمية الاختبار على النحو التالي: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

لذلك على سبيل المثال الخاص بك:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

ومع ذلك، أفضّل وضع اسم الطريقة التي يتم اختبارها أولاً، لأنه بعد ذلك يمكن ترتيب الاختبارات أبجديًا، أو تظهر مرتبة أبجديًا في مربع القائمة المنسدلة للأعضاء في VisStudio، ويتم تجميع جميع الاختبارات الخاصة بطريقة واحدة معًا.

---

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

بمعنى آخر أحب: Sum_ThrowsException_WhenNegativeNumberAs1stParam افضل من Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

Answer 4

أقوم بتسمية طرق الاختبار الخاصة بي مثل الطرق الأخرى باستخدام "PascalCasing" دون أي شرطات سفلية أو فواصل.أترك postfix امتحان بالنسبة للطريقة، لأنها لا تضيف أي قيمة.تشير السمة إلى أن الطريقة هي طريقة اختبار طريقة اختبار.

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

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

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

بالنسبة للطرق التي تختبر الاستثناءات أو الإجراءات غير الممكنة، أسبق طريقة الاختبار بالكلمة لا تستطيع.

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

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

Answer 5

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

أميل أيضًا إلى تضمين "اختبار" في مكان ما، إما في اسم الوظيفة أو في مساحة الاسم أو الفئة المرفقة.

Answer 6

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

Answer 7

أستخدم البادئة "T" لمساحات الأسماء والفئات والأساليب للاختبار.

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

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

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

يبدو تمامًا مثل اصطلاح تسمية الواجهات (أعني أنك لن تخلط بين الأشياء التي تبدأ بـ "I" ولن تخلط بينك وبين "T").

من السهل التجميع مع الاختبارات أو بدونها.

إنه أمر جيد من الناحية النظرية على أي حال، ويعمل بشكل جيد للمشاريع الصغيرة.