यूनिट टेस्ट के लिए कुछ लोकप्रिय नामकरण सम्मेलन क्या हैं?

सामान्य

  • सभी परीक्षणों के लिए समान मानकों का पालन करें।
  • प्रत्येक टेस्ट स्टेटस के बारे में स्पष्ट रहें।
  • अपेक्षित व्यवहार के बारे में विशिष्ट रहें।

उदाहरण

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) अंडरस्कोर द्वारा प्रत्येक शब्द को अलग करना

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
जोड़ा लेखक 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
जोड़ा
उपसर्ग के लिए एक अतिरिक्त तर्क। जब आप आईडीई में एक फ़ाइल खोज रहे हैं, तो आप आसानी से test और अपने क्लास नाम से शुरू करके परीक्षण मामलों को खोज सकते हैं। यदि वर्ग का नाम और टेस्ट क्लास नाम समान है, तो हमें हमेशा दो फाइलों के पथ को रोकना और पढ़ना होगा
जोड़ा लेखक THIS USER NEEDS HELP, स्रोत
थोड़ा विरोधाभास "जब तक यह पठनीय और स्पष्ट है" और "कौन ... परवाह करता है"। वैसे हर कोई परवाह करता है जब यह पठनीय और स्पष्ट नहीं होता है, इसलिए यही मायने रखता है। :-)
जोड़ा लेखक David Victor, स्रोत

मैं किसी भी अंडरस्कोर या विभाजक के बिना "पास्कलसीसिंग" का उपयोग करके अन्य विधियों जैसे अन्य परीक्षण विधियों का नाम देता हूं। मैं विधि के लिए पोस्टफिक्स टेस्ट छोड़ देता हूं, क्योंकि इसमें कोई मान नहीं है। यह तरीका एक परीक्षण विधि है TestMethod विशेषता द्वारा इंगित किया गया है।

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

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 शॉर्टकट का उपयोग करते हैं, आप कर सकते हैं   आसानी से अपने परीक्षण स्कैन करें और उन्हें अपने कोड के लिए एक spec की तरह पढ़ें।

मुझे यह दृष्टिकोण भी पसंद है:

MethodName_StateUnderTest_ExpectedBehavior

तो शायद इस पर समायोजित करें:

StateUnderTest_ExpectedBehavior

क्योंकि प्रत्येक परीक्षण पहले से ही घोंसला वाले वर्ग में होगा

0
जोड़ा
विजुअल स्टूडियो में रिशेर्पर के टेस्ट रनर का उपयोग करने वालों के लिए, उन्होंने 8.x में नेस्टेड टेस्ट क्लासेस का उपयोग करके बग फिक्स किया। तब से, यह अब तक मेरी पसंदीदा संरचना बन गया।
जोड़ा लेखक angularsen, स्रोत

मैं MethodName_DoesWhat_WhenTheseConditions के सम्मेलन का उपयोग करता हूं, उदाहरण के लिए:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

हालांकि, मुझे लगता है कि परीक्षण नाम इकाई परीक्षण संरचना का पालन करने के लिए बहुत कुछ है

  • व्यवस्था
  • अधिनियम
  • जोर

जो बीडीडी/गेरकिन सिंटैक्स का भी पालन करता है:

  • देखते हुए
  • जब
  • फिर

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

तो आपके उदाहरण के लिए:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

हालांकि, मैं पहले विधि का परीक्षण करने के लिए बहुत पसंद करता हूं, क्योंकि परीक्षणों को वर्णानुक्रम में व्यवस्थित किया जा सकता है, या VisStudio में सदस्य ड्रॉपडाउन बॉक्स में क्रमबद्ध रूप से क्रमबद्ध किया जा सकता है, और 1 विधि के लिए सभी परीक्षणों को एक साथ समूहीकृत किया जाता है।


किसी भी मामले में, मुझे अंडरस्कोर के साथ परीक्षण नाम के प्रमुख अनुभाग को अलग करना पसंद है, क्योंकि प्रत्येक शब्द के विपरीत, क्योंकि मुझे लगता है कि यह पढ़ने और बिंदु प्राप्त करना आसान बनाता है परीक्षण में से।

दूसरे शब्दों में, मुझे यह पसंद है: Sum_ThrowsException_WhenNegativeNumberAs1stParam Sum_Throws_Exception_When_Negative_Number_As_1st_Param से बेहतर है।

0
जोड़ा

जब तक आप एक अभ्यास का पालन करते हैं, यह वास्तव में कोई फर्क नहीं पड़ता। आम तौर पर, मैं एक विधि के लिए एक एकल इकाई परीक्षण लिखता हूं जिसमें एक विधि के लिए सभी भिन्नताओं को शामिल किया गया है (मेरे पास सरल तरीके हैं;) और फिर उन तरीकों के लिए परीक्षणों के अधिक जटिल सेट लिखें जिनकी आवश्यकता होती है। मेरी नामकरण संरचना आमतौर पर परीक्षण (जुनीट 3 से एक धारक) है।

0
जोड़ा

नामों का पहला सेट मेरे लिए अधिक पठनीय है, क्योंकि कैमेलकेसिंग शब्द और अंडरबार नामकरण योजना के अलग-अलग हिस्सों को अलग करता है।

मैं फ़ंक्शन नाम या संलग्न नामस्थान या कक्षा में कहीं भी "टेस्ट" शामिल करना चाहता हूं।

0
जोड़ा
@ फ्रैंक विधिनाम = ऊंटकेस विधिनाम = पास्कलकेस
जोड़ा लेखक Metro Smurf, स्रोत
@ मेट्रो-स्मरफ: दिलचस्प भेद, मैंने कभी पास्कलकेस शब्द का उपयोग नहीं किया है, और मैं इसे लंबे समय से कर रहा हूं। मुझे केवल माइक्रोसॉफ्ट डेवलपर सर्कल में पास्कलकेस शब्द दिखाई देता है, क्या आप ऐसा करते हैं?
जोड़ा लेखक Frank Szczerba, स्रोत
पास्कल केसिंग और ऊंट केसिंग के आसपास इतिहास (से: ब्रैड अब्राम - ब्लॉग .msdn.com/brada/archive/2004/02/03/67024.aspx ) ... "फ्रेमवर्क के प्रारंभिक डिजाइन में हमारे पास नामकरण शैली के बारे में सैकड़ों घंटों की बहस थी। इन बहसों को सुविधाजनक बनाने के लिए हम कई पदों का निर्माण किया। एंडर्स हेल्सबर्ग (टर्बो पास्कल का मूल डिजाइनर) डिजाइन टीम के एक प्रमुख सदस्य के साथ, इसमें कोई आश्चर्य की बात नहीं है कि हमने पास्कल प्रोग्रामिंग भाषा द्वारा लोकप्रिय आवरण शैली के लिए पास्कल केसिंग शब्द चुना है। "
जोड़ा लेखक Heliac, स्रोत

मैं टेस्ट नेमस्पेस, कक्षाओं और विधियों के लिए 'टी' उपसर्ग का उपयोग करता हूं।

मैं साफ-सुथरा होने और फ़ोल्डरों को बनाने की कोशिश करता हूं जो नामस्थानों को दोहराते हैं, फिर परीक्षणों के लिए एक परीक्षण फ़ोल्डर या अलग परियोजना बनाएं और बुनियादी परीक्षणों के लिए उत्पादन संरचना को दोहराएं:

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

मैं आसानी से देख सकता हूं कि कुछ परीक्षण है, मुझे पता है कि यह वास्तव में किस मूल कोड से संबंधित है, (यदि आप इसे काम नहीं कर सकते हैं, तो परीक्षण भी वैसे भी घुल गया है)।

यह सम्मेलन नामकरण इंटरफेस की तरह दिखता है, (मेरा मतलब है, आप 'मैं' से शुरू होने वाली चीजों से उलझन में नहीं आते हैं, न ही आप 'टी' के साथ करेंगे)।

परीक्षणों के साथ या बिना संकलन करना आसान है।

यह वैसे भी सिद्धांत में अच्छा है, और छोटी परियोजनाओं के लिए बहुत अच्छी तरह से काम करता है।

0
जोड़ा
मेरे लिए बहुत हंगरी (नोटेशन)। इसके अलावा, विज्ञापन ने कहा, उपसर्ग टी सामान्य जेनेरिक पैरामीटर के लिए प्रयोग किया जाता है।
जोड़ा लेखक Danny Varod, स्रोत
मैं मानता हूं, हंगेरियन नोटेशन को हटा दिया गया है और मानक जेनेरिक प्रकार पैरामीटर के साथ संघर्ष, मुझे इस मामले में लागू अपवाद नहीं दिख रहा है (जैसे इंटरफेस के लिए है)।
जोड़ा लेखक SonOfPirate, स्रोत
दिलचस्प दृष्टिकोण। कुछ लोग तर्क दे सकते हैं कि टी उपसर्ग जेनिक्स में उपयोग किए जाने वाले सम्मेलन के साथ संघर्ष करता है (उदा। Func (टी 1, टी 2, ट्रेशल्ट)), लेकिन जब तक टीम में सर्वसम्मति होती है तब तक मैं व्यक्तिगत रूप से परवाह नहीं करता हूं। नाम कम हैं जो चीजों को और भी पठनीय बनाता है।
जोड़ा लेखक stung, स्रोत
QAIndia
QAIndia
160 प्रतिभागियों की

QA India ! Unite Here we share job postings , prepare for interviews and share tips/techniques in QA. Please follow following guideline while sharing any job ... QA job # location : # title Company : Title : Requirement: Responsibility: Apply: