unit-testing
इकाई परीक्षण: सर्वोत्तम अभ्यास

परिचय

अच्छा नामकरण

अच्छे नामकरण का महत्व, कुछ बुरे उदाहरणों से स्पष्ट किया जा सकता है:

[Test]
Test1() {...} //Cryptic name - absolutely no information 

[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?

[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?

अच्छे परीक्षणों के लिए अच्छे नामों की आवश्यकता होती है। अच्छा परीक्षण विधियों, परीक्षण परिदृश्यों या आवश्यकताओं का परीक्षण नहीं करता है।

अच्छा नामकरण संदर्भ और अपेक्षित व्यवहार के बारे में जानकारी भी प्रदान करता है। आदर्श रूप से, जब परीक्षण आपके बिल्ड मशीन पर विफल हो जाता है, तो आपको यह तय करने में सक्षम होना चाहिए कि परीक्षण कोड को देखने के बिना, या यहां तक कि कठिन है, इसे डिबग करने की आवश्यकता है।

अच्छा नामकरण आपको कोड पढ़ने और डीबगिंग के लिए समय देता है:

[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

शुरुआती लोगों के लिए यह सुनिश्चित करने के लिए सहायक हो सकता है कि परीक्षण नाम EnsureThat_ या इसी तरह के उपसर्ग के साथ शुरू किया जाए । "EnsureThat_" परिदृश्य या आवश्यकता के बारे में सोचना शुरू करने में मदद करता है, जिसे एक परीक्षण की आवश्यकता है:

[Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

परीक्षण जुड़नार के लिए भी नामकरण महत्वपूर्ण है। कक्षा के परीक्षण के बाद परीक्षण का नाम बताएं:

[TestFixture]
public class OptionsTests //tests for class Options
{
    ...
}

अंतिम निष्कर्ष है:

अच्छा नामकरण अच्छे परीक्षणों की ओर जाता है जो उत्पादन कोड में अच्छे डिजाइन की ओर जाता है।

सरल से जटिल तक

लेखन वर्गों के साथ समान - सरल मामलों के साथ शुरू करें, फिर आवश्यकता (उर्फ परीक्षण) और कार्यान्वयन (उर्फ उत्पादन कोड) मामले में जोड़ें:

[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf4() {...}
[Test]
public void EnsureThat_IsNOTLeapYearIfDecimalMultipleOf100 {...}
[Test]
public void EnsureThat_IsLeapYearIfDecimalMultipleOf400 {...}

आवश्यकताओं के साथ समाप्त होने पर, रीफैक्टरिंग चरण को न भूलें - पहले कोड को रिफलेक्टर करें, फिर परीक्षणों को रिफलेक्टर करें

जब काम पूरा हो जाए, तो आपके पास अपनी कक्षा का पूर्ण और अद्यतन दस्तावेज होना चाहिए।

MakeSut अवधारणा

उत्पादन कोड के रूप में टेस्टकोड की समान गुणवत्ता की मांग है। MakeSut ()

• पठनीयता में सुधार
• आसानी से refactored जा सकता है
• पूरी तरह से निर्भरता इंजेक्शन का समर्थन करता है।

यहाँ अवधारणा है:

[Test]
public void TestSomething()
{
    var sut = MakeSut();
    
    string result = sut.Do();
    Assert.AreEqual("expected result", result);
}

सबसे सरल मेकसट () अभी परीक्षण किया गया वर्ग लौटाता है:

private ClassUnderTest MakeSUT()
{
    return new ClassUnderTest();
}

जब निर्भरता की आवश्यकता होती है, तो उन्हें यहां इंजेक्ट किया जा सकता है:

private ScriptHandler MakeSut(ICompiler compiler = null, ILogger logger = null, string scriptName="", string[] args = null)
{
    //default dependencies can be created here
    logger = logger ?? MockRepository.GenerateStub<ILogger>();
    ...
}

कोई कह सकता है, कि मेकसट सेटअप और टैडरडाउन तरीकों के लिए एक सरल विकल्प है, जो टेस्ट्रनर फ्रेमवर्क द्वारा प्रदान किया गया है और इन विधियों को टेस्ट स्पेसिफिक सेटअप और टियरडाउन के लिए बेहतर जगह बना सकता है।

हर कोई खुद तय कर सकता है कि किस तरीके का इस्तेमाल करना है। मेरे लिए MakeSut () बेहतर पठनीयता और अधिक लचीलापन प्रदान करता है। अंतिम लेकिन कम से कम, अवधारणा किसी भी वृत्ताकार ढांचे से स्वतंत्र है।