इकाई परीक्षण विकास

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



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



एक इकाई परीक्षण के 3 संशोधनों पर विचार करें, जो मुझे एक वास्तविक परियोजना में मिला।

प्रयास नंबर 1

इस इकाई परीक्षण का पहला संस्करण यह था:

public class ReferenceNumberTest { @Test public void testValidate() { assertFalse( ReferenceNumber.validate("1234567890123") ); assertFalse( ReferenceNumber.validate("1234567") ); assertTrue( ReferenceNumber.validate("12345678") ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

प्रयास नंबर 2

कुछ बिंदु पर, डेवलपर ने आया और टीडीडी से कुछ " सर्वोत्तम प्रथाओं " को इस कोड पर लागू करने का फैसला किया: परीक्षण विधि को कई छोटे लोगों में तोड़ दें, ताकि उनमें से प्रत्येक ने केवल एक चीज का परीक्षण किया, और उन्हें संबंधित नाम दें।



यहाँ उसने क्या किया:

 public class ReferenceNumberTest { @Test public void testTooLong() { String len13 = "1234567891111"; assertEquals(len13.length(), 13); assertEquals(ReferenceNumber.validate(len13), false); } @Test public void testTooShort() { String len7 = "1234567"; assertEquals(len7.length(), 7); assertEquals(ReferenceNumber.validate(len7), false); } @Test public void testOk() { String len8 = "12345678"; assertEquals(len8.length(), 8); assertEquals(ReferenceNumber.validate(len8), true); String len12 = "123456789111"; assertEquals(len12.length(), 12); assertEquals(ReferenceNumber.validate(len12), true); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम इसे एक अच्छी इकाई परीक्षा कहते हैं। इसे पढ़ना बहुत आसान है: चर के नामों से यह अनुमान लगाना आसान है कि 13 वर्ण बहुत अधिक हैं, 7 बहुत कम हैं, और 8 वर्ण सामान्य हैं।

प्रयास नंबर 3

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



डेवलपर विभाजन और नाम बदलने की प्रक्रिया जारी रखता है:

 public class ReferenceNumberTest { @Test public void nullIsNotValidReferenceNumber() { assertFalse(ReferenceNumber.validate(null)); } @Test public void referenceNumberShouldBeShorterThan13() { assertFalse(ReferenceNumber.validate("1234567890123")); } @Test public void referenceNumberShouldBeLongerThan7() { assertFalse(ReferenceNumber.validate("1234567")); } @Test public void referenceNumberShouldContainOnlyNumbers() { assertFalse(ReferenceNumber.validate("1234567ab")); assertFalse(ReferenceNumber.validate("abcdefghi")); assertFalse(ReferenceNumber.validate("---------")); assertFalse(ReferenceNumber.validate(" ")); } @Test public void validReferenceNumberExamples() { assertTrue(ReferenceNumber.validate("12345678")); assertTrue(ReferenceNumber.validate("123456789")); assertTrue(ReferenceNumber.validate("1234567890")); assertTrue(ReferenceNumber.validate("12345678901")); assertTrue(ReferenceNumber.validate("123456789012")); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम इसे BDD स्टाइल स्पेसिफिकेशन कहते हैं । विधियों के नाम लगभग मानव भाषा बोलते हैं कि कोड कैसे काम करना चाहिए। पूंजी पत्रों से पहले मानसिक रूप से स्थान डालना, हमें अंग्रेजी में कोड का एक विनिर्देश मिलता है। यह समझने के लिए कि कक्षा कैसे काम करती है, हमें कोड में नहीं आना चाहिए - बस शीर्षक पढ़ें। और अगर, एक कोड परिवर्तन के दौरान, इसमें एक त्रुटि हुई थी और यूनिट परीक्षण टूट गया था, तो हम शायद टूटी हुई परीक्षण विधि के नाम से निर्धारित कर सकते हैं कि कोड में किस तरह की त्रुटि हुई थी।

वैसे, मैं तेलिन में BDD पर devclub.eu संगोष्ठी में यूनिट टेस्ट के विकास का यह उदाहरण दिखाने जा रहा था। और इसलिए, संगोष्ठी से एक दिन पहले, मैंने पाया कि मैं स्वयं रेफरनंबर क्लास के स्रोत कोड की नकल करना भूल गया हूं, जिसका हम यहां परीक्षण कर रहे हैं। क्या करें? आतंक! सेमिनार से पहले एक दिन शेष! मुझे तत्काल इसे फिर से लिखने की आवश्यकता थी।



अब इन तीनों परीक्षण कक्षाओं को देखें और सोचें कि किसने मुझे रेफ़रनंबर वर्ग के तर्क को बहाल करने में मदद की।

और अंत में, बी.डी.डी.

हम कह सकते हैं कि तीसरा संस्करण पिछले वाले से अलग है जिसमें यह वर्ग के व्यवहार का वर्णन करता है । यह "चाहिए" और "समाहित" जैसे शब्दों के उपयोग के माध्यम से प्राप्त किया जाता है: "मेरी कक्षा को इस तरह से व्यवहार करना चाहिए और" "," मेरी विधि को यह और वह करना चाहिए। "



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



आप JUnit से Easyb में अनुवादित उसी उदाहरण को देखकर इसे सत्यापित कर सकते हैं :

 description "ReferenceNumber" it "should not be null", { ReferenceNumber.validate(null).shouldBe false } it "should be shorter than 13", { ReferenceNumber.validate("1234567890123").shouldBe false } it "should be longer than 7", { ReferenceNumber.validate("1234567").shouldBe false } it "should contain only numbers", { ReferenceNumber.validate("1234567ab").shouldBe false ReferenceNumber.validate("abcdefghi").shouldBe false ReferenceNumber.validate("---------").shouldBe false ReferenceNumber.validate(" ").shouldBe false } it "valid reference number examples", { ReferenceNumber.validate("12345678").shouldBe true ReferenceNumber.validate("123456789").shouldBe true ReferenceNumber.validate("1234567890").shouldBe true ReferenceNumber.validate("12345678901").shouldBe true ReferenceNumber.validate("123456789012").shouldBe true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

इन विशिष्टताओं के परीक्षण के शुभारंभ पर रिपोर्ट वास्तव में प्रलेखन के रूप में काम कर सकती है:

इसके अलावा और इसके अलावा, बीडीडी में अन्य महत्वपूर्ण शब्द हैं, जैसे कि, कब और फिर, साथ ही पहले और बाद में, और यह भी सुनिश्चित करें, कथा और "जैसा व्यवहार करना चाहिए"। BDD न केवल यूनिट परीक्षणों के लिए, बल्कि कार्यात्मक / एकीकरण परीक्षणों के लिए भी उपयुक्त है, लेकिन यह पहले से ही इस लेख के दायरे से परे है। अब हम यूनिट परीक्षणों के स्तर में रुचि रखते हैं। इस लेख का उद्देश्य यह दिखाना है कि उन्हें विभिन्न तरीकों से लिखा जा सकता है।

यह जोड़ना बाकी है कि BDD विनिर्देशों को लिखने के लिए पुस्तकालय अन्य भाषाओं के लिए भी उपलब्ध हैं: जावा ( JDave , JBehave ), Ruby ( RSpec , RBehave , Cucumber ), Groovy ( Easyb ), Scala ( Scala-test ), PHP ( Behat ), CPP () CppSpec ), .Net ( SpecFlow , Shouldly ), पायथन ( लेट्यूस , ककड़ी )।

और अगर, आपके नियंत्रण से परे कारणों के लिए, आप JUnit से किसी और चीज़ में स्थानांतरित नहीं कर सकते - कुछ भी नहीं, बस तीसरा उदाहरण याद रखें। वैसे, इस मामले में हार्मकेस्ट लाइब्रेरी आपके लिए उपयोगी है।



जैसा कि कोज़मा प्रुतकोव को वसीयत की गई: कॉमरेड, बीडीडी!