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



लेकिन मुझे लगता है कि इसका एक मुख्य कारण यह है कि लोग यह नहीं जानते हैं कि कहां से शुरू किया जाए। इसलिए मैंने यूनिट परीक्षणों के बारे में एक लेख पढ़ा, मुझे यह पसंद आया; फैसला किया कि हमें किसी दिन कोशिश करनी चाहिए। लेकिन आगे क्या है? कहाँ से शुरू करें? इन सभी आवश्यकताओं का आविष्कार कैसे करें, परीक्षण विधियों का नाम कैसे दें?



हाल ही में, इकाई परीक्षणों को बीडीडी विशिष्टताओं में बदलने की प्रवृत्ति लोकप्रियता प्राप्त कर रही है, अर्थात यह कहती है कि एक अच्छी इकाई परीक्षा में कुछ परीक्षण नहीं करना चाहिए, लेकिन कार्यक्रम के व्यवहार का वर्णन करना चाहिए। लेकिन इस लानत व्यवहार का वर्णन कैसे करें; इन सभी परीक्षण मामलों के लिए नामों के साथ आने की प्रेरणा कहाँ से मिली?



इस पर चर्चा की जाएगी:

प्रेरणा कहां से प्राप्त करें

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



इसलिए, यूनिट परीक्षण लिखने के लिए प्रेरणा के मेरे शीर्ष -5 स्रोत।

5. प्रमुख को रिपोर्ट करें

बैठक में हर सुबह, बॉस आपसे पूछता है, "कल आपने क्या किया था?"

- उसने बग को ठीक किया।

बॉस केवल एक शब्द नहीं लेता है और खुदाई जारी रखता है:

- क्या बग?

- ठीक है, validateReferenceNumber विधि तय की।

- अधिक विशेष रूप से, आपने वहां क्या तय किया?

"ठीक है, पहले यह दुर्घटनाग्रस्त हो गया था यदि आप इसे इनपुट पर एक खाली स्ट्रिंग देते हैं, और अब यह गिरता नहीं है, लेकिन यह गलत है।"



पकड़ लिया!



आप देखते हैं, एक व्यावहारिक रूप से समाप्त इकाई परीक्षण आपकी नाक के सामने हवा में लटका हुआ है। बैठक के बाद, कंप्यूटर पर बैठें और लिखें:

public class ReferenceNumberTest { @Test public void emptyStringIsNotValidReferenceNumber() { assertFalse(validateReferenceNumber("")); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

आदर्श रूप से, आपको यह कल करना चाहिए था, और फिर बॉस देख सकता था कि कल आपने किस इकाई परीक्षण को जोड़ा और आपको अपने सवालों से परेशान नहीं किया।

मैं मजाक नहीं कर रहा हूं, मैं बहुत सफल कंपनियों के उदाहरण जानता हूं जिसमें कोड समीक्षा के बजाय, यूनिट परीक्षणों की समीक्षा की जाती है।

4. सहयोगियों के साथ स्पष्टीकरण

एक सहकर्मी हर दिन आपके पास आता है और पूछता है:

- सुनो, मैं यहाँ आपके कोड को डीबग करने, डिबग करने के लिए हूँ, लेकिन फिर भी मैं यह नहीं समझ सकता कि यह कैसे काम करता है?

आप धैर्यपूर्वक उसे समझाएं:

- अच्छा, देखो, देखो: बी यहां आता है, और ए यहां से निकलता है

"मैं अभी भी नहीं समझ पा रहा हूं, लेकिन क्यों ए?"

"ठीक है, क्योंकि सभी पत्र जो कि मुझसे छोटे हैं, के लिए इस विधि को अगला पत्र वापस करना चाहिए।"

- आह, अब यह स्पष्ट है



और फिर से पकड़ लिया!



आपने स्वयं, इस पर संदेह किए बिना, केवल परीक्षण मामले का नाम तैयार किया है।

सहकर्मी के कर्म के लिए मानसिक रूप से +1 भेजते हुए, वे बैठ गए और लिखा:

 public class NanoTechnologySecurityTest { @Test public void shouldReturnNextLetterForAllLettersExceptJa() { assertEquals("", encodeLetter("")); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3. एक ग्राहक के साथ बातचीत

किसी भी सुंदर दिन पर, ग्राहक कॉल करके कह सकता है:

- याद रखें, हमने चर्चा की है कि जैसे ही फ़ील्ड फोकस खोता है फॉर्म पर सभी फ़ील्ड्स को स्वचालित रूप से मान्य किया जाना चाहिए? इसलिए, मैंने अपना विचार बदल दिया। मैंने अपनी दादी को बीटा संस्करण दिखाया, और उसने कहा कि यह स्पष्ट नहीं था, और आमतौर पर अजाक्स बेकार है । जब ग्राहक "सबमिट" बटन पर क्लिक करता है, तो फ़ील्ड को केवल तभी मान्य किया जाए ।



और फिर, पकड़ लिया!



ग्राहक ने हमारे लिए केवल परीक्षण मामले का पाठ तैयार किया है।



ग्राहक के कर्म के लिए मानसिक रूप से -10 भेजने, हम बैठ गए और लिखा ... यूआई परीक्षण, सामान्य इकाई परीक्षणों की तुलना में थोड़ा अधिक जटिल हैं, लेकिन यह कुछ इस तरह दिख सकता है:

 public class TimotiFanClubRegistrationFormTest { @Test public void shouldValidateFieldsOnFormSubmission() { Form form = new Form(); assertTrue(form.isValid()); form.submit(); assertFalse(form.isSubmitted()); assertFalse(form.isValid()); form.setName("Baba Njura"); form.setEmail("Baba.Njura@yandex.ru"); form.submit(); assertTrue(form.isSubmitted()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. बग

हर दिन, आप जीरा जाते हैं (और जो वास्तव में भाग्यशाली है - Pivotal Tracker के लिए ) और आप पाते हैं कि दुर्भावनापूर्ण परीक्षकों ने आपके कार्यक्रम में बग ढूंढ लिया है। यदि आप परीक्षक के साथ भाग्यशाली हैं, तो बग का वर्णन कुछ इस तरह लगता है: "यदि आप तीन बार गलत पासवर्ड दर्ज करते हैं, तो खाता अवरुद्ध होना चाहिए, लेकिन यह मेरे लिए अवरुद्ध नहीं होगा। मैंने पहले ही पंद्रह बार प्रवेश किया है। "



परीक्षक को धन्यवाद देने के लिए मानसिक रूप से (उसके पास से पर्याप्त और धन्यवाद, आप अभी भी अपने कर्म को नहीं बचा सकते हैं), बैठो और लिखो:

 public class LoginPageTest { @Test public void shouldBlockAccountAfter3UnsuccessfulTries() { LoginPage page = new LoginPage(); page.login("vasjok47", "Toiota"); page.login("vasjok47", "Tojota"); page.login("vasjok47", "tayota"); assertTrue(AccountDAO.getAccount("vasjok47).isBlocked()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

1. प्रतिबद्ध संदेश (यह रूसी में कैसे है?)

यह मेरा पसंदीदा बिंदु है, मैं इस पर अधिक विस्तार से ध्यान देना चाहूंगा।



जब आप कोड बदलते हैं, तो आमतौर पर इसका एक कारण होता है। आमतौर पर कारण यह है कि आप चाहते हैं कि यह कोड कुछ अलग तरीके से करे (हम रीफैक्टरिंग, प्रदर्शन में सुधार और फेंग शुई के लिए कोष्ठक की नियुक्ति को छोड़कर)।



मान लीजिए कि हमारे पास एक कोड है जो ईमेल को मान्य करता है। विशेष रूप से, उन्होंने जाँच की कि ईमेल के अंत में एक अवधि और दो अक्षर होने चाहिए। और यहां तक ​​कि उसके लिए एक इकाई परीक्षण भी है, सब कुछ वैसा ही है जैसा लोगों के पास है। और फिर यह अचानक पता चला कि अवधि के बाद अधिक पत्र हो सकते हैं, उदाहरण के लिए, कुछ ग्राहकों के लिए ईमेल ".info" के साथ समाप्त होता है। किए जाने की तुलना में जल्दी नहीं, कोड तय किया गया था, और यहां तक ​​कि एक पंक्ति को मौजूदा इकाई परीक्षण में जोड़ा गया था:

 public class EmailValidatorTest { @Test public void testValidateEmail() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info")); // 4 letters now allowed! } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और अब हम इस व्यवसाय को सीवीएस (और जो भाग्यशाली हैं, एसवीएन में हैं, और जो आमतौर पर भाग्यशाली हैं, जीआईटी में ) करना चाहते हैं।

एक कमिट के लिए, आपको एक स्पष्टीकरण (कमिट मैसेज) लिखना होगा, जिसमें वे आमतौर पर लिखते हैं, लेकिन कोड में क्या बदलाव आया है। और आप लिखते हैं:

 svn commit -m "       ."
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और यही असली गोत्र है!



यह वही है जो हमें चाहिए। अभी तक एन्टर प्रेस न करें।

हमने रोका, इस पाठ को माउस से उजागर किया। यूनिट टेस्ट क्लास खोली। उन्होंने टेस्ट लिखा, कॉपी किए गए पाठ को चिपकाया और अंग्रेजी में अनुवाद किया। आप स्वाद के लिए थोड़ा स्पष्ट या सामान्य कर सकते हैं।

 public class EmailValidatorTest { @Test public void validEmailShouldEndWithDotFollowedBySeveralLetters() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info")); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब आप अपने कर्म को सुरक्षित रूप से और मानसिक रूप से +1 भेज सकते हैं। आज हम हवा से कुछ ज्ञान को और अधिक मूर्त बनाने में सक्षम थे। अब यह ज्ञान कहीं भी नहीं जाएगा और परियोजना की प्रत्येक विधानसभा में स्वचालित रूप से जाँच की जाएगी।



खैर, यह बहुत अच्छा नहीं है?