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


203

सामान्य

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

उदाहरण

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

अन्य

  • टेस्ट के साथ अंतिम नाम
  • वर्ग नाम के साथ विधि नाम प्रारंभ करें

जवाबों:


94

मैं इस एक आदमी पर आपके साथ बहुत अधिक हूं। आपके द्वारा उपयोग किए जाने वाले नामकरण परंपराएं हैं:

  • प्रत्येक परीक्षण अवस्था क्या है, इसके बारे में स्पष्ट करें।
  • अपेक्षित व्यवहार के बारे में विशिष्ट।

टेस्ट नाम से आपको और क्या चाहिए?

के विपरीत रे के जवाब के मुझे नहीं लगता कि टेस्ट उपसर्ग आवश्यक है। यह परीक्षण कोड है, हम जानते हैं कि। यदि आपको कोड की पहचान करने के लिए ऐसा करने की आवश्यकता है, तो आपको बड़ी समस्याएं हैं, आपके परीक्षण कोड को आपके उत्पादन कोड के साथ नहीं मिलाया जाना चाहिए।

अंडरस्कोर की लंबाई और उपयोग के लिए, इसके परीक्षण कोड , कौन परवाह करता है? केवल आप और आपकी टीम इसे देखेंगे, इसलिए जब तक यह पठनीय है, और परीक्षण क्या कर रहा है, इसके बारे में स्पष्ट है! :)

उस ने कहा, मैं अभी भी अपने रोमांच के साथ परीक्षण और ब्लॉगिंग के लिए काफी नया हूँ :)


20
थोड़ा विरोधाभास "जब तक यह पठनीय है, और स्पष्ट है" और "कौन ... परवाह करता है"। अच्छी तरह से हर कोई परवाह करता है जब यह पठनीय और स्पष्ट नहीं होता है, इसलिए यही मायने रखता है। :-)
डेविड विक्टर

1
उपसर्ग के लिए एक अतिरिक्त तर्क। जब आप आईडीई में एक फ़ाइल खोज रहे हैं, तो आप आसानी से Testऔर अपने वर्ग के नाम के साथ शुरू करके परीक्षण मामलों की खोज कर सकते हैं । यदि कक्षा का नाम और परीक्षण वर्ग का नाम समान है, तो हमें हमेशा दो फ़ाइलों का मार्ग रोकना और पढ़ना होगा
यह USER NEEDS HELP

@THISUSERNEEDSHELP मुझे लगता है कि src / libs & src / परीक्षणों की तरह एक अच्छा फ़ोल्डर संरचना होने से आपकी बात आसानी से दूर हो सकती है । मैं कुछ परीक्षण धावक फ्रेमवर्क की तरह एक उपसर्ग की आवश्यकता होती है पता परीक्षण परीक्षण कोड की पहचान के लिए, इसलिए ऐसे मामलों में टाला नहीं किया जाएगा, लेकिन बाकी के लिए यह एक दोहराव हो सकता है कोई आवश्यक उपसर्ग।
नीग्रोटिको 19

@ negrotico19 मैं मामले में सोच रहा हूं जैसे कि इंटेलीज में जब आप Search Everywhere(शिफ्ट शिफ्ट) या Find a Class By Name(सीएमडी ओ)। मुझे लगता है कि इसे फ़ोल्डर संरचना या मॉड्यूल संरचना द्वारा विभेदित किया जाएगा , लेकिन जब हम कुछ खोजते हैं, तो हम पहले से ही जानते हैं कि हम क्या खोजना चाहते हैं। उदाहरण के लिए, यदि मुझे परीक्षण रहा हूँ, क्या मैं अपनी खोज को सीमित करना चाहते testहैं और फिर बल्कि नाम खोज से नाम के लिए खोज, और उसके बाद बाहर परीक्षण मैन्युअल रूप से आंखों के आधार पर फ़िल्टर। यह एक छोटा सा अंतर है, लेकिन "टेस्ट [क्लास नेम]" का परीक्षण करना बहुत आसान है और केवल एक ही पॉप अप और मानसिक भार को कम करना है
THIS USER NEEDS HELP

37

यह भी पढ़ने लायक है: स्ट्रक्चरिंग यूनिट टेस्ट

संरचना में प्रति कक्षा एक परीक्षण कक्षा है जिसका परीक्षण किया जा रहा है। यह इतना असामान्य नहीं है। लेकिन जो बात मेरे लिए असामान्य थी, वह यह थी कि परीक्षण के लिए प्रत्येक विधि के लिए उनके पास एक नेस्टेड वर्ग था।

जैसे

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

क्योंकि प्रत्येक परीक्षा पहले से ही एक नेस्टेड वर्ग में होगी


2
Visual Studio में Resharper के परीक्षण धावक का उपयोग करने वालों के लिए, उन्होंने 8.x में नेस्टेड टेस्ट कक्षाओं का उपयोग करते हुए कीड़े को ठीक किया। तब से, यह मेरी पसंदीदा संरचना बन गई।
एंगुलरसेन

क्या यह मायने रखता है कि नाम वास्तव में मेथडनाम_स्टैट यूंडरटैस्ट_एक्सपेक्टेडबहेवियर एप्रोच के साथ लंबा हो जाता है? जैसे कि "InitializeApiConfiguration_MissingApiKey_IllegalArgumentException"। क्या यह वास्तव में एक अच्छा परीक्षण नाम है?
portfoliobuilder

28

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

Sum_ThrowsException_WhenNegativeNumberAs1stParam

हालाँकि, मैं जो कुछ देख रहा हूँ, वह यह है कि परीक्षण नाम को इकाई परीक्षण संरचना का अनुसरण करना है

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

जो बीडीडी / घेरकिन सिंटैक्स का अनुसरण करता है:

  • दिया हुआ
  • कब
  • फिर

जो इस तरीके से परीक्षा को नाम देगा: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

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

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

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


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

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


22

मैं बिना किसी अंडरस्कोर या विभाजक के "पास्कल कैसिंग" का उपयोग करते हुए अन्य तरीकों की तरह अपने परीक्षण तरीकों का नाम देता हूं। मैं विधि के लिए पोस्टफिक्स टेस्ट छोड़ देता हूं , क्योंकि इसका कोई मूल्य नहीं है। यह विधि एक परीक्षण विधि है जिसे विशेषता 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.
}

ब्रायन कुक के "टीडीडी टिप्स: टेस्ट नेमिंग कन्वेंशन एंड गाइडलाइन्स" लेख पर मेरा नामकरण का अनुमान है । मुझे यह लेख बहुत मददगार लगा।


1
मेरी पोस्ट के लिंक के लिए +1 - हालांकि आपके टेस्ट में "टेस्ट" उपसर्ग का उपयोग करना अनावश्यक है। सुनिश्चित करें कि आपके परीक्षण अपेक्षित व्यवहार को निर्दिष्ट करते हैं। उदाहरण के लिए, CanRetrieveProperCountWhenAddingMultipleItems ()
bryanbcook

2
मुझे यह पसंद नहीं है क्योंकि इसमें अपेक्षित व्यवहार शामिल नहीं है
जोहान्स रूडोल्फ

5

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

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


2
@Frank मेथडनाम = कैमलकेज़ मेथडनाम = पास्कलकेस
मेट्रो स्मर्फ

@ मेट्रो-स्मर्फ: दिलचस्प अंतर, मैंने कभी पास्कलकेस शब्द का इस्तेमाल नहीं किया है, और मैं लंबे समय से ऐसा कर रहा हूं। मैं केवल माइक्रोसॉफ्ट डेवलपर सर्कल में पास्कलकेस शब्द को देखता हूं, क्या आप ऐसा करते हैं?
फ्रैंक स्जगबग्गा

पास्कल कैसिंग और कैमल कैसिंग के आसपास का इतिहास (से: ब्रैड अब्राम्स - blogs.msdn.com/brada/archive/2004/02/03/67024.aspx ) ... "फ्रेमवर्क के शुरुआती डिज़ाइन में हमारे पास सैकड़ों घंटे थे नामकरण शैली के बारे में बहस। इन बहसों को सुविधाजनक बनाने के लिए हमने कई शर्तें गढ़ीं। एंडर्स हील्सबर्ग (टर्बो पास्कल के मूल डिजाइनर) के साथ डिजाइन टीम के एक प्रमुख सदस्य, यह कोई आश्चर्य नहीं है कि हमने केसिंग शैली के लिए पास्कल केसिंग शब्द चुना। पास्कल प्रोग्रामिंग भाषा द्वारा लोकप्रिय। "
हेलिक

-3

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


-8

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

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

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

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

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

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

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


3
दिलचस्प दृष्टिकोण। कुछ लोग यह तर्क दे सकते हैं कि T उपसर्ग का उपयोग आप जिन जेनरिक (उदाहरण के लिए func (T1, T2, TResult)) में करते हैं, उनके साथ संघर्ष होता है, लेकिन मैं व्यक्तिगत रूप से तब तक परवाह नहीं करता जब तक कि टीम के भीतर एक आम सहमति न हो। नाम कम हैं जो चीजों को अधिक पठनीय बनाते हैं।
डंक मार

मेरे लिए बहुत हंगेरियन (संकेतन)। इसके अलावा, विज्ञापन डंठल कहा जाता है, उपसर्ग टी का उपयोग सामान्य प्रकार के मापदंडों के लिए किया जाता है।
डैनी व्रोड

मैं सहमत हूं, हंगेरियन नोटेशन को समाप्त कर दिया गया है और क्योंकि मानक सामान्य प्रकार के मापदंडों के साथ संघर्ष, मैं इस मामले में एक अपवाद लागू नहीं देखता हूं (जैसे इंटरफेस के लिए है)।
SonOfPirate
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.