यूनिट टेस्ट लिखते समय परीक्षण करने के लिए क्या करें?

Question

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

वर्तमान में हम कोडेस्मिथ का उपयोग करके हमारे सभी बेस क्लास उत्पन्न करते हैं जो पूरी तरह से डेटाबेस में टेबल पर आधारित होते हैं। मैं इन बेस वर्गों के साथ परीक्षण मामलों को उत्पन्न करने के लाभों के रूप में उत्सुक हूं? क्या यह खराब परीक्षण प्रथा है?

इससे मुझे मेरी पोस्ट का अंतिम प्रश्न मिल जाता है। यूनिट टेस्ट का उपयोग करते समय हम क्या परीक्षण करते हैं?

क्या हम उन उदाहरणों का परीक्षण करते हैं जिन्हें हम जानते हैं हम चाहते हैं? या हम उन उदाहरणों का परीक्षण करते हैं जिन्हें हम नहीं चाहते हैं?

उनके ऐसे तरीके हो सकते हैं जिनमें विफल होने के कई तरीके हैं और सफलता के कई तरीके हैं, हम कैसे जानते हैं कि कब रुकना है?

उदाहरण के लिए एक सारांश समारोह लें। इसे 1,2 दें और केवल यूनिट परीक्षण में 3 की उम्मीद करें .. हम कैसे जानते हैं कि 5,6 35 वापस नहीं आ रहा है?

प्रश्न संक्षिप्त

• उत्पन्न इकाई परीक्षण (गुड/बुरा)
• क्या/हम कितना परीक्षण करते हैं?

Answer 1

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

class Adder { public int Add(int x, int y) { return x + y; } } 

और एक इसी इकाई परीक्षण

[Test] 
public void Add_returns_that_one_plus_two_is_three() { 
    Adder a = new Adder(); 
    int result = a.Add(1, 2); 
    Assert.AreEqual(3, result); 
} 

है तो यह आपके कुछ (लेकिन 100%) विश्वास है कि परीक्षण के अंतर्गत विधि उचित रूप से व्यवहार कर रहा है देता है। यह आपको रिफैक्टरिंग पर कोड तोड़ने के खिलाफ कुछ बचाव भी देता है।

यूनिट टेस्ट का उपयोग करते समय हम परीक्षण करते हैं?

अपेक्षित (या निर्दिष्ट) व्यवहार के विरुद्ध आपके सार्वजनिक तरीकों का वास्तविक व्यवहार।

क्या हम उन उदाहरणों का परीक्षण करते हैं जिन्हें हम जानते हैं हम चाहते हैं?

हाँ, एक तरह से अपने विधि की शुद्धता में विश्वास हासिल करने की उम्मीद उत्पादन के लिए acutal उत्पादन, ज्ञात उम्मीद उत्पादन के साथ कुछ इनपुट लेने के इनपुट पर सार्वजनिक विधि निष्पादित और तुलना करने के लिए है।

Answer 2

अपनी आवश्यकताओं के साथ शुरू करें और अपेक्षित व्यवहार का परीक्षण करने वाले परीक्षण लिखें। उस बिंदु से, आप कितने अन्य परिदृश्यों का परीक्षण कर सकते हैं, आपके शेड्यूल द्वारा या शायद आपके पहचानने वाले गैर-सफल परिदृश्यों द्वारा संचालित किया जा सकता है जो विशेष रूप से उच्च जोखिम वाले होते हैं।

आप केवल (या आपके उपयोगकर्ताओं) को खोजने वाले दोषों के जवाब में गैर-सफलता परीक्षण लिखने पर विचार कर सकते हैं (यह विचार यह है कि आप एक परीक्षण लिखते हैं जो वास्तव में दोष को ठीक करने से पहले दोष सुधार का परीक्षण करता है, ताकि आपका परीक्षण होगा असफल हो अगर भविष्य में विकास में आपके दोष में उस दोष को फिर से पेश किया गया हो)।

Answer 3

1) शुरू करने के लिए, मैं आपको अपने ऐप के मूल तर्क का परीक्षण करने की सलाह दूंगा।

2) फिर, यह देखने के लिए बनाम कोड कोड टूल का उपयोग करें कि क्या आपका सभी कोड परीक्षणों में उपयोग किया जाता है (यदि अन्य सभी शाखाएं, केस की स्थिति लागू की जाती है)। यह 1 + 2 = 3, 5 + 6 = 35 परीक्षण के बारे में आपके प्रश्न का उत्तर है: जब कोड कवर किया जाता है, तो आप आगे के प्रयोगों से सुरक्षित महसूस कर सकते हैं।

3) यह कोड का 80-90% को कवर करने के लिए एक अच्छी आदत है: काम के बाकी आमतौर पर unefficient है: ही टिककर खेल-setters, 1 लाइन अपवाद हैंडलिंग, आदि

4) चिंताओं की जुदाई के बारे में जानें ।

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

Answer 4

परीक्षण करने के लिए क्या: सब कुछ जो कभी गलत हो गया है।

जब आपको कोई बग मिलती है, तो से पहले आप कोड को ठीक करते हैं, तो एक परीक्षण लिखें। फिर, जब कोड सही तरीके से काम कर रहा है, तो परीक्षण पास हो जाएगा, और आपके शस्त्रागार में एक और परीक्षण होगा।

Answer 5

आप unittest बातें जहां

• सुनिश्चित करें कि आपके एल्गोरिथ्म काम करता है
• भविष्य

में आकस्मिक परिवर्तन के खिलाफ की रक्षा करना चाहते हैं तो अपने उदाहरण में यह बहुत मतलब नहीं होगा बनाना चाहते उत्पन्न कक्षाओं का परीक्षण करने के लिए। इसके बजाय जनरेटर का परीक्षण करें।

मुख्य उपयोग मामलों (परीक्षण किए गए फ़ंक्शन को किसके लिए डिज़ाइन किया गया था) का परीक्षण करना अच्छा अभ्यास है। फिर आप मुख्य त्रुटि मामलों का परीक्षण करते हैं। फिर आप कोने के मामलों (यानी निचले और ऊपरी सीमाओं) के लिए परीक्षण लिखते हैं। असामान्य त्रुटि के मामले आमतौर पर उत्पादन के लिए इतना कठिन होते हैं कि यह यूनिट-टेस्ट करने के लिए समझ में नहीं आता है।

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

आप कितनी चीजें परीक्षण करते हैं, प्रयास बनाम वापसी का मामला है, इसलिए यह वास्तव में व्यक्तिगत परियोजना पर निर्भर करता है। आम तौर पर आप 80/20 नियमों का पालन करने का प्रयास करते हैं, लेकिन ऐसे अनुप्रयोग हो सकते हैं जहां आपको अधिक परीक्षण कवरेज की आवश्यकता हो क्योंकि विफलता के बहुत गंभीर परिणाम होंगे।

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

Answer 6

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

Answer 7

तीन बुनियादी घटनाएं हैं जिनके लिए मैं परीक्षण करता हूं: न्यूनतम, अधिकतम, और कहीं भी न्यूनतम और अधिकतम के बीच।

और जहां उचित दो चरम सीमाएं: नीचे न्यूनतम, और अधिकतम से ऊपर।

स्पष्ट अपवाद हैं (कुछ कोड में उदाहरण के लिए न्यूनतम या अधिकतम नहीं हो सकता है) लेकिन मुझे पता चला है कि इन घटनाओं के लिए इकाई परीक्षण एक अच्छी शुरुआत है और कोड के साथ "सामान्य" मुद्दों का बहुमत कैप्चर करता है।