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

جنرال لواء

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

أمثلة

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown() 

Public void Sum_simpleValues_Calculated ()

Source: Naming standards for Unit Tests

2) فصل كل كلمة من جانب الشرطة Underscore

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 ()

آخر

  • End method names with Test
  • Start method names with class name
0
وأضاف تحرير
الآراء: 1
وأضاف المؤلف Wedge, مصدر

7 إجابة

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

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

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

Contrary to Ray's answer I don't think the Test prefix is necessary. It's test code, we know that. If you need to do this to identify the code, then you have bigger problems, your test code should not be mixed up with your production code.

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

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

0
وأضاف
وسيطة إضافية واحدة للبادئة. عندما تبحث عن ملف في IDE ، يمكنك البحث بسهولة عن حالات الاختبار عن طريق البدء باستخدام Test واسم الفصل. إذا كان اسم الفئة واسم اختبار الفئة متطابقًا ، فسوف يتعين علينا دائمًا إيقاف وقراءة مسار الملفين
وأضاف المؤلف THIS USER NEEDS HELP, مصدر
تناقض طفيف "طالما أنه قابل للقراءة ، واضح" و "من ... يهتم". جيدًا ، الجميع يهتمون عندما لا يكونوا قابلين للقراءة والوضوح ، ولهذا السبب يهم. :-)
وأضاف المؤلف David Victor, مصدر

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

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

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

[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.
}

My naming convension are base on the article "TDD Tips: Test Naming Conventions & Guidelines" of Bryan Cook. I found this article very helpful.

0
وأضاف
لا يعجبني ذلك لأنه لا يشمل السلوك المتوقع
وأضاف المؤلف Johannes Rudolph, مصدر
إجراء 1+ للارتباط بنشرتي - على الرغم من أنه من غير الضروري استخدام بادئة "اختبار" في اختباراتك. تأكد من أن اختباراتك تحدد السلوك المتوقع. على سبيل المثال ، CanRetrieveProperCountWhenAddingMultipleItems ()
وأضاف المؤلف bryanbcook, مصدر

This is also worth a read: Structuring Unit Tests

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

مثلا

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

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

0
وأضاف
لأولئك الذين يستخدمون عداء اختبار Resharper في Visual Studio ، إصلاح الأخطاء باستخدام فصول الاختبار المتداخلة في 8.x. منذ ذلك الحين ، أصبح هذا الهيكل المفضل لدي إلى حد بعيد.
وأضاف المؤلف angularsen, مصدر

أميل إلى استخدام اصطلاح MethodName_DoesWhat_WhenTheseConditions حتى على سبيل المثال:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

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

  • وترتيب </لى>
  • وقانون </لى>
  • وتأكيد </لى>

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

  • ونظرا </لى>
  • وعندما </لى>
  • وبعد ذلك </لى>

which would be to name the test in the manner of: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

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

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

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


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

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

0
وأضاف

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

0
وأضاف

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

أنا أيضا تميل إلى تضمين "اختبار" في مكان ما ، إما في اسم الدالة أو مساحة الاسم أو الفهرس.

0
وأضاف
Frank methodName = camelCase MethodName = PascalCase
وأضاف المؤلف Metro Smurf, مصدر
@ metro-smurf: تمييز مثير للاهتمام ، لم أسمع أبدًا مصطلح PascalCase المستخدم ، ولقد كنت أفعل ذلك لفترة طويلة. أرى فقط مصطلح PascalCase طرح في الدوائر المطورين مايكروسوفت ، هل هذا ما تفعله؟
وأضاف المؤلف Frank Szczerba, مصدر
التاريخ حول غلاف Pascal Casing و Camel Casing (من: Brad Abrams - blog .msdn.com/brada/archive/2004/02/03/67024.aspx ) ... "في التصميم المبدئي للإطار ، كان لدينا مئات الساعات من النقاش حول أسلوب التسمية. لتسهيل هذه المناقشات ، صاغ عدد من المصطلحات ، فمع أندرس هيليسبيرغ (المصمم الأصلي لـ Turbo Pascal) هو عضو رئيسي في فريق التصميم ، فلا عجب أننا اخترنا مصطلح Pascal Casing لأسلوب التغليف الذي اشتهرت به لغة برمجة Pascal. "
وأضاف المؤلف Heliac, مصدر

أستخدم بادئة 'T' لاختبار مساحات الأسماء والفئات والطرق.

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

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

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

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

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

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

0
وأضاف
مجري جدا (تدوين) بالنسبة لي. أيضا ، ad stung المذكور ، يتم استخدام البادئة T لمعلمات النوع العامة.
وأضاف المؤلف Danny Varod, مصدر
أوافق ، تم تخدير الترميز الهنغاري ولأن التعارض مع معلمات النوع القياسي القياسية ، لا أرى استثناءًا ينطبق في هذه الحالة (مثل وجود الواجهات).
وأضاف المؤلف SonOfPirate, مصدر
نهج للاهتمام. قد يجادل بعض الناس بأن البادئة T تتعارض مع الاتفاقية التي تستخدمها في علم الأدوية (مثل func (T1، T2، Tresult)) ، لكنني شخصياً لا أهتم طالما يوجد إجماع داخل الفريق. الأسماء قصيرة مما يجعل الأمور أكثر قابلية للقراءة أيضا.
وأضاف المؤلف stung, مصدر