क्या वैज्ञानिक शोध कोड के लिए इकाई परीक्षण लिखना सार्थक है?

89

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

क्या हमें शोध कोड के लिए यूनिट टेस्ट लिखना चाहिए?

programming-paradigms testing

— डेविड केचेसन
स्रोत

2

यह एक खुला सवाल है, यह नहीं है?

— क्वेटते

2

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

— लेगरबेर

स्टैकओवरफ़्लो पर एक प्रश्न पर एक समान नस में कुछ अच्छी चर्चा है ।

— n

software-carpentry.org/blog/2014/10/…

— n

85

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

फिर मैंने टेस्ट ड्रिवेन डेवलपमेंट का उपयोग करना शुरू कर दिया और मुझे यह पूर्ण रहस्योद्घाटन मिला। मुझे अब दृढ़ता से विश्वास हो गया है कि मेरे पास इकाई-परीक्षण लिखने का समय नहीं है ।

मेरे अनुभव में, आप क्लीनर इंटरफेस, अधिक फोकस्ड क्लास और मॉड्यूल और आम तौर पर अधिक ठोस , परीक्षण योग्य कोड के साथ समाप्त होने वाले परीक्षण को ध्यान में रखते हुए विकसित करते हैं ।

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

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

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

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

स्पष्टता के लिए, और @ naught101 ने पूछा ...

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

हालांकि खोजपूर्ण कोड को विकसित करने की स्थिति में भी, मैं एक महत्वपूर्ण लाभ देख सकता हूं कि मान्यताओं को संहिताबद्ध करने के साथ-साथ यह देखने की क्षमता भी है कि उन मान्यताओं को समय के साथ कैसे विकसित किया जाता है।

— मार्क बूथ
स्रोत

7

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

— naught101

35

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

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

$h$ $C h^r$ $r$ $r$

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

इस तरह के कई परीक्षण हैं, जिनमें संरक्षण और स्थिरता परीक्षण शामिल हैं। ऑपरेशन यह नहीं है कि प्रतिगमन (आप एक परीक्षण चलाते हैं और मानक के विपरीत आउटपुट की जांच करते हैं) से अलग है, लेकिन मानक आउटपुट पिछले रन के बजाय एक विनिर्देश से आता है।

— मैट नेप्ले
स्रोत

4

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

— डेविड केचेसन 19

यही कारण है कि मैंने पोस्ट के शीर्ष पर स्पष्ट कर दिया है कि मैं इकाई परीक्षणों का व्यापक दृष्टिकोण लेता हूं, और "आमतौर पर" का अर्थ बिल्कुल यही होता है।

— मैट नेप्ले

मेरा प्रश्न इकाई परीक्षणों की अधिक व्यापक रूप से स्वीकृत परिभाषा के अर्थ में था। मैंने अब इसे प्रश्न में पूरी तरह से स्पष्ट कर दिया है।

— डेविड केचेसन 19

मैंने अपना उत्तर स्पष्ट कर दिया है

— २०:०२ पर मैट नेप्ले

आपके बाद के उदाहरण मेरे इरादे के अनुकूल हैं।

— डेविड केचेसन

28

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

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

यूनिट टेस्टिंग के साथ-साथ स्टैटिक कोड एनालिसिस, मेमोरी डीबगर्स, और कंपाइलर वॉर्निंग फ्लैग के साथ कंप्लीट करना सिंपल एरर्स और अनयूज्ड कोड को पकड़ना।

— ज्योफ ऑक्सबेरी
स्रोत

संबंधित प्रश्न प्रोग्रामर

— ।stackexchange.com

क्या आप एकीकरण परीक्षणों पर पर्याप्त विचार करेंगे, या आपको लगता है कि आपको अलग इकाई परीक्षण लिखने की भी आवश्यकता है?

— सियामी

मैं जहाँ भी संभव हो अलग इकाई परीक्षण लिखूँगा और ऐसा करना संभव होगा। यह डिबगिंग को आसान बनाता है, और डिकोड किए गए कोड को लागू करता है (जो आप चाहते हैं)।

— ज्योफ ऑक्सीबेरी

19

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

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

मैं निश्चित रूप से आपके आवेदन में कम से कम कुछ महत्वपूर्ण मॉड्यूल के लिए इसकी सिफारिश करूंगा। हालांकि, किसी को यह महसूस करना होगा कि यह बहुत थकाऊ और समय लेने वाला है, जब तक कि आपके पास असीमित मैन-पावर न हो, मैं इसे 100% एक जटिल कोड के लिए अनुशंसित नहीं करूंगा।

— FrenchKheldar
स्रोत

क्या आपके पास कोई विशिष्ट उदाहरण या मानदंड हैं कि कौन से टुकड़ों को इकाई परीक्षण (और कौन सा नहीं) चुनने के लिए?

— डेविड केचेसन

@DavidKetcheson मेरा अनुभव हमारे द्वारा उपयोग किए जाने वाले एप्लिकेशन और भाषा तक सीमित है। इसलिए हमारे सामान्य उद्देश्य के लिए ज्यादातर F90 की 200k लाइनों के साथ CFD कोड, हम पिछले एक या दो वर्षों से कोशिश कर रहे हैं कि कोड की कुछ कार्यात्मकताओं को वास्तव में अलग कर सकें। एक मॉड्यूल बनाना और पूरे कोड में इसका उपयोग करना यह हासिल नहीं कर रहा है, इसलिए किसी को इन मॉड्यूलों की वास्तव में तुलना करना है और व्यावहारिक रूप से उन्हें लाइब्रेरी बनाना है। इसलिए केवल बहुत कम USE स्टेटमेंट और बाकी कोड के साथ सभी कनेक्शन रूटीन कॉल के माध्यम से किए जाते हैं। दिनचर्या कि आप निश्चित रूप से, साथ ही साथ पुस्तकालय के बाकी हिस्सों को एकजुट कर सकते हैं।

— फ्रेंचकेवलडर

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

— फ्रेंचकेवलर

1

इकाई परीक्षण के अतिरिक्त अन्य प्रकार के सॉफ्टवेयर परीक्षण (एकीकरण, प्रणाली) को क्यों नहीं शामिल किया गया? समय और लागत के अलावा, यह सबसे पूर्ण तकनीकी समाधान नहीं होगा? मेरे संदर्भ 1 (धारा 3.4.2) और 2 (पृष्ठ 5) हैं। दूसरे शब्दों में, क्या सोर्स कोड को पारंपरिक सॉफ्टवेयर परीक्षण स्तरों 3 ("परीक्षण स्तर") द्वारा परीक्षण नहीं किया जाना चाहिए ?

— ximiki

14

वैज्ञानिक कोड के लिए यूनिट परीक्षण कई कारणों से उपयोगी है।

विशेष रूप से तीन हैं:

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

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

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

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

आप कागज़ 7 की सर्वश्रेष्ठ प्रथाओं पर सह-शोधित किए गए पेपर I की धारा 7 "गलतियों के लिए योजना" में विवरण, सबूत और संदर्भ पा सकते हैं - यह उपयोगी प्रोग्रामिंग का पूरक अवधारणा भी प्रस्तुत करता है।

— नील च्यू होंग
स्रोत

9

मेरी deal.II कक्षाओं में मुझे लगता है कि सॉफ्टवेयर परीक्षण की जरूरत नहीं है कि सही ढंग से काम नहीं करता है (और तनाव मैं उद्देश्यपूर्ण ने कहा कि "पर जाने सिखाना है ठीक से काम नहीं", नहीं " हो सकता है ठीक से काम नहीं)।

बेशक मैं मंत्र द्वारा जी रहा हूं - जो कि सौदा है। मैं हर प्रतिबद्ध के साथ 2,500 परीक्षण चलाने आया हूं;;

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

— वोल्फगैंग बंगर्थ
स्रोत

आप इस पदानुक्रम (निचले के लिए इकाई, उच्च के लिए प्रतिगमन) बनाम सॉफ्टवेयर परीक्षण में पारंपरिक स्तरों का प्रस्ताव क्यों देते हैं ?

— ximiki

@smiki - मेरा मतलब यह नहीं है। मैं कह रहा हूं कि परीक्षण एक स्पेक्ट्रम पर मौजूद हैं, जिसमें आपके लिंक में सूचीबद्ध सभी श्रेणियां शामिल होंगी।

— वोल्फगैंग बैंगर्थ

8

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

— स्टेफानो बोरीनी
स्रोत

7

पूर्ण रूप से!

क्या, यह आपके लिए पर्याप्त नहीं है?

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

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

— सज्जन
स्रोत

+1: "इस तरह से चरणों में काम करने का अर्थ है कि जब आप किसी समस्या में भाग लेते हैं, तो आपके पास परीक्षण के लिए केवल सबसे हाल का 'चरण' होता है, पहले के चरणों का पहले ही परीक्षण हो चुका होता है।"

— ximiki

5

हाँ।

किसी भी कोड को इकाई परीक्षणों के बिना लिखा जाने वाला विचार एक अनहता है। जब तक आप अपने कोड को सही साबित नहीं करते हैं और तब प्रमाण को सही साबित करते हैं = P।

— aterrel
स्रोत

3

... और फिर आप यह साबित करते हैं कि सबूत सही है, और ... अब यह एक गहरा खरगोश छेद है।

— JM

2

कछुए नीचे सभी तरह से दिज्क्स्त्र को गौरवान्वित करते हैं!

— ऐंटरेल

2

बस सामान्य मामले को हल करें, और फिर अपना प्रमाण खुद को सही साबित करें! कछुओं की धार!

— ऐसिन

5

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

वैज्ञानिक कोड में यूनिट परीक्षणों (या वास्तव में किसी भी परीक्षण) के साथ एक बहुत अधिक महत्वपूर्ण समस्या यह है कि फ्लोटिंग-पॉइंट अंकगणित की अनिश्चितताओं से कैसे निपटें। जहां तक मुझे पता है कि अभी तक कोई अच्छा सामान्य समाधान नहीं हैं।

— khinsen
स्रोत

चाहे आप मैन्युअल रूप से परीक्षण करते हैं या स्वचालित रूप से इकाई परीक्षणों का उपयोग करते हैं, आपको फ्लोटिंग पॉइंट प्रतिनिधित्व के साथ बिल्कुल वही समस्याएं हैं। मैं अत्यधिक रिचर्ड हैरिस 'की सिफारिश करेंगे उत्कृष्ट श्रृंखला में लेख के ACCU s' अधिभार पत्रिका ।

— मार्क बूथ

"यदि किसी दिए गए फ़ंक्शन के लिए फ़ंक्शन के कोड को दोहराए बिना इस तरह के परीक्षण लिखने का कोई तरीका नहीं है, तो न करें"। क्या आप विस्तार से समझा सकते हैं? एक उदाहरण यह मेरे लिए स्पष्ट कर देगा।

— ximiki

5

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

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

— user69
स्रोत

+1: "सुनिश्चित करें कि कोड किनारों पर व्यवहार करता है और सुंदर तरीके से विफल रहता है (हालांकि आप इसे अपने सिमुलेशन में परिभाषित करते हैं) जब इनपुट पैरामीटर या डेटा स्वीकार्य सीमाओं के बाहर गिरता है।"

— ximiki

5

मैंने कण भौतिकी में अपने शोध प्रबंध विश्लेषण कोड के तीसरे संस्करण सहित कई छोटे पैमाने (अर्थात एकल प्रोग्रामर) कोड पर अच्छे प्रभाव के लिए यूनिट परीक्षण का उपयोग किया है ।

पहले दो संस्करण अपने स्वयं के वजन और अंतर्संबंधों के गुणन के तहत ढह गए थे।

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

— dmckee
स्रोत

3

एक अलग दृष्टिकोण जिसे मैंने एक रासायनिक सॉल्वर (जटिल भूवैज्ञानिक डोमेन के लिए) विकसित करते समय इस्तेमाल किया था, जिसे आप कॉपी और पेस्ट स्निपेट द्वारा यूनिट परीक्षण कह सकते थे ।

एक बड़े रासायनिक प्रणाली मॉड्यूलर में एम्बेडेड मूल कोड के लिए एक परीक्षण दोहन का निर्माण समय सीमा में संभव नहीं था।

हालांकि, मैं स्निपेट्स के एक तेजी से जटिल सेट को काम करने में सक्षम था, जिसमें दिखाया गया था कि कैसे (बूस्ट स्पिरिट) पार्सर ने रासायनिक अभिव्यक्तियों के लिए काम किया, विभिन्न अभिव्यक्तियों के लिए यूनिट टेस्ट के रूप में।

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

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

— एंडी डेंट
स्रोत

2

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

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

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

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

मैं दोनों के लिए इसका इस्तेमाल सामान्य ऑपरेशन के दौरान इनपुट और आउटपुट meshes मूल्यांकन करने के लिए कर सकते हैं और इसका इस्तेमाल करने के बाद मैं एल्गोरिदम बदल दिया एक मानसिक स्वास्थ्य की जांच के लिए। जब मैं एल्गोरिथ्म को बदलता हूं तो मुझे हमेशा नहीं पता होता है कि क्या नया परिणाम बेहतर है, क्योंकि अक्सर कोई पूर्ण उपाय नहीं होता है जो कि अनुमानित सबसे अच्छा है। लेकिन ऐसे मेट्रिक्स उत्पन्न करके मैं कुछ कारकों के बारे में बता सकता हूं जो बेहतर है जैसे "नए वेरिएंट में अंत में एक बेहतर कोण अनुपात है लेकिन एक बदतर अभिसरण दर"।

— allo
स्रोत