📓 👨‍🌾 🚴🏼 परीक्षणों के लिए परीक्षण 👎🏼 🗾 🎨

इस सवाल का सबसे आम जवाब "मैं इकाई परीक्षण क्यों नहीं लिख रहा हूँ" यह सवाल है "मेरे परीक्षणों के लिए परीक्षण कौन लिखेगा?" इस बात की क्या गारंटी है कि मेरे परीक्षणों में कोई त्रुटि नहीं होगी? ”, जो इकाई परीक्षणों के सार की एक गंभीर गलतफहमी को इंगित करता है।

इस लेख का उद्देश्य इस बिंदु को संक्षेप में और स्पष्ट रूप से कैप्चर करना है ताकि कोई असहमति न हो।

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

assertEquals(5, hypotenuse(3, 4));

आपको खुद इन परीक्षण मूल्यों के साथ आना होगा: कागज के एक टुकड़े पर या कैलकुलेटर पर एक कॉलम में गिनें।

बेशक, यह परीक्षा पर्याप्त है या नहीं। यदि आपके विशिष्ट कार्य में यह बहुत महत्वपूर्ण है कि फ़ंक्शन बहुत कम संख्या में सही ढंग से काम करता है, तो आपको एक अलग परीक्षण जोड़ना चाहिए
 assertEquals(0.00005, hypotenuse(0.00003, 0.00004));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

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

नियम

तो, यूनिट टेस्ट उस कार्यक्रम से अलग है:

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

पहला पैराग्राफ प्रश्न का उत्तर है "मेरे परीक्षणों के लिए परीक्षण कौन लिखेगा?" चूंकि एक इकाई परीक्षण एक कार्यक्रम की तुलना में परिमाण सरल का एक आदेश है, इसके लिए एक परीक्षण को परिमाण सरल का एक आदेश लिखना होगा, लेकिन यह लगभग असंभव है, क्योंकि यह वैसे भी बेहद सरल है।

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

UPD: kalantyr हमें बताता है कि यूनिट परीक्षण और कोड एक दूसरे का परीक्षण करते हैं क्योंकि वे परस्पर जुड़े हुए हैं। यही है, एक अर्थ में, परीक्षणों के लिए परीक्षण स्वयं परीक्षण किए गए कोड हैं।

उदाहरण

आइए यहां एक इकाई परीक्षण का एक न्यूनतम उदाहरण देने की कोशिश करें जो उपरोक्त सभी को दिखाता है। मान लीजिए हमें एक फ़ंक्शन लिखने की ज़रूरत है जो यह तय करती है कि क्या एक दिया गया वर्ष एक लीप वर्ष है। आपको याद दिला दूं कि एक लीप वर्ष एक ऐसा वर्ष होता है जिसे 4 से विभाजित किया जाता है, उन वर्षों के अपवाद के साथ जो 100 से विभाजित होते हैं लेकिन 400 से विभाजित नहीं होते हैं।

 public class LeapYear { public static boolean isLeap(int year) { return year % 4 == 0 && year % 100 != 0 || year % 400 == 0; } } import org.junit.Test; import static junit.framework.Assert.*; public class LeapYearTest { @Test public void yearDividing4IsLeap() throws Exception { assertTrue(isLeap(2008)); assertTrue(isLeap(2012)); assertFalse(isLeap(2011)); } @Test public void exceptYearDividing100WhichIsNotLeap() throws Exception { assertFalse(isLeap(1900)); assertFalse(isLeap(2100)); } @Test public void exceptYearDividing400WhichIsLeap() throws Exception { assertTrue(isLeap(1600)); assertTrue(isLeap(2000)); } }

जैसा कि आप देख सकते हैं, परीक्षण के मामलों के अंदर स्वयं ठोस सरल उदाहरण हैं: 2000, 2008, 1011. मैंने खुद ही उनका आविष्कार किया, मेरे सिर से। और परीक्षण मामलों के नाम मानव भाषा में उन्हें (संक्षेप में) समझाते हैं। ध्यान दें कि एक-पर-एक परीक्षण विधियों के नाम ऊपर "लीप वर्ष" शब्द के विवरण के समान हैं। तो यह होना चाहिए: परीक्षण को प्रलेखन के रूप में पढ़ा जाना चाहिए। और यह कैसा दिखता है, उदाहरण के लिए, IDEA में:

5.97 केबी

त्रुटियों

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

पहली आम गलती कुछ भी जांचना नहीं है। उदाहरण के लिए:

 @Test public void testLeapYear() throws Exception { int year = 2004; assertEquals(2004, year); }

यह इकाई परीक्षण व्यर्थ है क्योंकि यह हमारे कार्यक्रम का परीक्षण नहीं करता है। वह जो अधिकतम जांच करता है वह यह है कि जावा सही ढंग से काम करता है, लेकिन यह व्यामोह है। ओरेकल को ऐसा करने दो।

स्पष्ट असावधानी के बावजूद, यह ऐसे परीक्षणों के साथ है कि हर कोई जो सबसे पहले जूनीत को चुनता है।

दूसरी सामान्य गलती यह है कि प्रोग्राम में होने वाले टेस्ट में उसी तर्क को दोहराने की कोशिश करें। उदाहरण के लिए:

 @Test public void testLeapYear() throws Exception { for (int i=0; i<100000; i++) { assertEquals(i % 4 == 0 && i % 100 != 0 || i % 400 == 0, isLeap(i)); } }

यह इकाई परीक्षण इस कारण से खराब है कि एक प्रोग्रामर इसमें उतनी ही गलतियाँ कर सकता है जितनी कि कोड में।

बदबू आ रही है

संकेत है कि इकाई परीक्षण गलत है:

स्थितियां और चक्र

यदि आप एक इकाई परीक्षण में स्थितियां और चक्र देखते हैं, तो यह एक स्पष्ट संकेत है कि परीक्षण गलत है। छोरों से छुटकारा पाने की कोशिश करें और कुछ सरल उदाहरण लिखें।

^{बेशक, एक परीक्षण में छोरों की कभी-कभी आवश्यकता होती है, उदाहरण के लिए, दो सरणियों की तुलना करने के लिए।} ^{बल्कि, इसका मतलब था कि परीक्षण के तहत कार्यक्रम में उसी तर्क के साथ चक्र नहीं होना चाहिए।}
परीक्षण विधि का नाम यह नहीं कहता है कि क्या काम करना चाहिए।

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

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

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

खुला स्रोत

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

मुझे उम्मीद है कि यह लेख शाश्वत बहस को रोक देगा कि यूनिट परीक्षण बेकार, समय लेने वाली, आदि हैं, और आगे की चर्चा के लिए शुरुआती बिंदु के रूप में सेवा कर सकते हैं कि कैसे लिखना है, कितना लिखना है, क्या लिखना है, और इसी तरह। और किसी को हब से दूर तोड़ने और " टेस्ट ड्रिवेन डेवलपमेंट (केंट बेक) ", " xUnit टेस्ट पैटर्न (जेरार्ड मेस्जारोस) " और मेरे पसंदीदा " क्लीन कोड " (रॉबर्ट सी। मार्टिन ) जैसी गंभीर किताबें पढ़ने में भी बुद्धिमानी हो सकती है । ) "।

परीक्षण करना या न करना - यह सवाल नहीं है ...

परीक्षणों के लिए परीक्षण

नियम

उदाहरण

त्रुटियों

बदबू आ रही है

खुला स्रोत

More articles: