आप अपने यूनिट परीक्षणों के साथ क्या परीक्षण करते हैं?

Question

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

1. यदि मेरे पास कोई कार्यवाही विधि है जो डेटा की एक सूची देता है, तो मुझे क्या सत्यापित करना चाहिए? केवल दृश्य नाम सही है, या मुझे डेटा भी सत्यापित करना चाहिए?
2. यदि मुझे डेटा का भी परीक्षण करना चाहिए, तो क्या मैं दो बार एक ही कोड नहीं लिखूंगा? डेटा का परीक्षण करने का क्या उपयोग है, यदि मैं उस डेटा को पुनर्प्राप्त करने के लिए उसी विधि का उपयोग करता हूं जिसका मैं तुलना कर रहा हूं?
3. क्या मुझे अपने डेटा को जोड़ने/संपादित करने के तरीकों का परीक्षण करना चाहिए? मैं कैसे सत्यापित करूं कि रिकॉर्ड को सही तरीके से जोड़ा/संपादित/हटा दिया गया है?

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

उदाहरण के रूप में - मेरे पास एक गेस्टबुक कंट्रोलर है (पोस्ट करने जा रहा है), पोस्ट देखने, जोड़ने, संपादित करने और हटाने के तरीकों के साथ। मुझे परीक्षण करने की क्या ज़रूरत है? मैं यह कैसे करुं?

Answer 1

यूनिट परीक्षण (यूटी)! = टेस्ट प्रेरित डिजाइन (TDD)

इस भ्रम काफी आम हो रहा है। यूटी कोड कवरेज के बारे में सब कुछ है। टीडीडी फीचर्स से संबंधित है। वे एक ही बात नहीं है [क्षमा करें जोएल!]

यूटी के साथ, आप जो भी कोड चाहते हैं उसे लिखते हैं, फिर वापस जाएं और प्रत्येक समारोह (यहां तक ​​कि कुछ छोटे-छोटे लोगों) का परीक्षण करें।

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

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

यदि आप केवल पांच विशिष्ट चीजों को करने के लिए एक ऐप लिख रहे हैं, तो अकेले टीडीडी पर्याप्त होना चाहिए।

Answer 2

1. किसी दिए गए इनपुट या राज्य के लिए, आपको यह जांचना चाहिए कि विधि का वापसी मूल्य जैसा आप उम्मीद करेंगे। यदि आपकी विधि बहुत से प्रकार के डेटा लौटाती है, तो आपको यह सत्यापित करना चाहिए कि वे सभी सही हैं।
2. अपने परीक्षण मामले में नमूना डेटा के एक छोटे से सेट का उपयोग करें। डिस्क या डेटाबेस से कुछ भी लोड न करें। एक स्ट्रिंग में पास करें या परीक्षण में ऑब्जेक्ट का परीक्षण करें। यह देखते हुए कि डेटा के छोटे सेट से आप अपनी विधि से बहुत विशिष्ट परिणाम प्राप्त कर सकते हैं, जिसे आप अपने वास्तविक परिणाम से तुलना करते हैं। आप अपने परीक्षण में आपके लिए मूल्यों की गणना करने वाले बहुत से कोड से बचना चाहते हैं, क्योंकि तब आपको यह सुनिश्चित करने के लिए अपने परीक्षणों के लिए परीक्षण लिखना होगा कि वे ठीक से काम करते हैं!
3. आपके द्वारा लिखे गए कोड के हर बिट का परीक्षण करें। एक रिकॉर्ड जोड़ने के लिए (यदि आपके परीक्षण एक परीक्षण डेटाबेस तक लगाए गए हैं) तो आप बस अंतिम डाले गए रिकॉर्ड के लिए पूछ सकते हैं, या पहले और बाद में रिकॉर्ड के कुल अंक की तुलना कर सकते हैं और यह सुनिश्चित कर सकते हैं कि यह एक से बढ़े। यदि आपके पास मॉकिंग/स्टबिंग फ्रेमवर्क है तो आप डेटाबेस को छोड़ सकते हैं और जोर दे सकते हैं कि डेटाबेस को चीजों को सहेजने वाली विधि को कॉल किया गया था। एक संपादन का परीक्षण करने के लिए बस संपादित रिकॉर्ड को फिर से डेटाबेस को पुनः प्राप्त करें और जोर दें कि मान को पुराने मूल्य से बदल दिया गया है। या यदि मॉकिंग/स्टबिंग, कि विशेषता मान बदलने की विधि सही ढंग से बुलाया गया था।

लेकिन वास्तव में, लिखने के बारे में कोड के बिट के लिए एक परीक्षा लिखें। इसे असफल देखो। फिर इसे पास करने के लिए बस पर्याप्त कोड लिखें। अब एक और परीक्षण लिखें और दोहराना।

Answer 3

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

मुझे उपयोगकर्ता कहानियों से परीक्षण लिखना वास्तव में उपयोगी लगता है। अधिकांश समय मैं उपयोगकर्ता कहानियों को शुरू करने से टॉप-डाउन स्टाइल परीक्षण लिखता हूं। उदाहरण के लिए हमारी उपयोगकर्ता कहानी इस तरह के कार्य को दूषित करती है:

1. जब उपयोगकर्ता ऑर्डर व्यू को सहेजता है तो सूचना संदेश प्रदर्शित करना चाहिए।

मैं आमतौर पर प्रस्तुति/नियंत्रक परत

[Test] 
    public void When_User_Save_Order_View_Should_Display_Information_Message() 
    { 
     using (mockRepository.Record()) 
     { 
      repository.Save(order); 
      view.Message= "Order saved successfully"; 
     } 

     using (mockRepository.Playback()) 
     { 
      presenter = new OrderSavePresenter(view, orderRepository); 
      presenter.Save(); 
     } 
    } 

से इस कहानी के लिए परीक्षण लिखें और फिर मैं प्रत्येक वर्गों है कि मैं मज़ाक उड़ाया या जरूरत के लिए परीक्षण लिखने के लिए जारी है।

Answer 4

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

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

उदाहरण के लिए, किसी ने "addElements (स्ट्रिंग [] तत्व)" जैसे एक विधि को बदल दिया। उन्होंने "int (int i = 0; i < = elements.length; i ++) का उपयोग करने की कोशिश की"। जब चेक-इन के बाद यूनिट परीक्षण चलाया गया था और इसे ठीक किया गया था तो बाध्य अपवाद से बाहर निकला था।

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

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

Answer 5

टेस्ट मॉड्यूल के इंटरफ़ेस का अनुबंध परीक्षण किए जाने:

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

ग्राहक द्वारा मेरा मतलब है कि आपकी कक्षा का उपयोग करने वाला कोड।
अपेक्षित व्यवहार से मेरा मतलब है कि वापसी मूल्यों और ऑब्जेक्ट राज्यों पर एक विधि का अपेक्षित परिणाम।

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

Answer 6

ये सामान्य दिशा निर्देशों इकाई परीक्षण के लिए मैं उपयोगी पाते हैं:

1) सीमा ऑब्जेक्ट (विन/WebForms, CustomControls आदि) की पहचान करें।

2) नियंत्रण ऑब्जेक्ट (व्यापार परत वस्तुओं की पहचान)

3) ईकाई परीक्षण लिखें करने के लिए नियंत्रण सीमा वस्तुओं द्वारा लाया सार्वजनिक तरीकों वस्तुओं कम से कम के लिए सुनिश्चित करें।

इस तरह आप सुनिश्चित होंगे कि आप अपने ऐप के मुख्य कार्यात्मक पहलुओं (विशेषताओं) को कवर कर रहे हैं और आप माइक्रो-परीक्षण (जब तक आप चाहें) का जोखिम नहीं चलाते हैं।

Answer 7

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

कैसे TDD करने के लिए के उदाहरण: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

इसके अलावा Writing standards for unit testing से मेरा उत्तर देखते हैं - यह उदाहरण और अधिक जानकारी के लिए संपर्क हैं। यहां अनुसरण करने के लिए भी अच्छे लिंक दिए गए हैं: http://code.google.com/p/instinct/wiki/UsersGuide

Answer 8

मुझे लगता है कि यहां Shu-Ha-Ri का थोड़ा सा हिस्सा है। आप एक प्रश्न पूछ रहे हैं जो समझाना मुश्किल है। यह टीडीडी लागू करने के लिए अभ्यास करने और संघर्ष करने के बाद ही है कि आपको क्या मिलेगा। तब तक हम आपको जवाब देंगे जो समझ में नहीं आता है, आपको Monads Are Burritos की चपेट में सामान बता रहा है। इससे आपकी मदद नहीं होगी और हम बेवकूफों की तरह आवाज करेंगे (मोनैड स्पष्ट रूप से नींबू-शिफॉन पाई हैं)।

मैं केंट बेक के TDD book और इसके माध्यम से काम करने की सलाह देना चाहता हूं, और फिर बस अभ्यास कर रहा हूं। "Ri के लिए कोई शाही सड़क नहीं है।"