इकाई परीक्षण और परीक्षण-संचालित विकास के लिए रणनीतियाँ

Question

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

• सामान्य तौर पर आप किसी दिए गए जटिल समस्या को प्राथमिकता के लिए सटीक उत्तर नहीं जानते हैं, इसलिए आप एक परीक्षण कैसे लिख सकते हैं?

• समानता की डिग्री बदलती है; मुझे हाल ही में एक बग का सामना करना पड़ा जहां 3 में से कई के रूप में एमपीआई कार्यों का उपयोग करना विफल होगा, लेकिन 2 में से कई ने काम किया। इसके अतिरिक्त, आम परीक्षण रूपरेखाएं MPI की प्रकृति के कारण बहुत MPI के अनुकूल नहीं लगती हैं - आपको कार्यों की संख्या में परिवर्तन करने के लिए एक परीक्षण बाइनरी को फिर से निष्पादित करना होगा।

• वैज्ञानिक कोड में अक्सर बहुत कसकर युग्मित, अन्योन्याश्रित और विनिमेय भागों होते हैं। हम सभी ने विरासत कोड को देखा है, और हम जानते हैं कि अच्छी डिजाइन को त्यागना और वैश्विक चर का उपयोग करना कितना आकर्षक है।

• अक्सर एक संख्यात्मक विधि एक "प्रयोग" हो सकती है, या कोडर पूरी तरह से समझ नहीं पाता है कि यह कैसे काम करता है और इसे समझने की कोशिश कर रहा है, इसलिए अनुमानित परिणाम असंभव है।

परीक्षणों के कुछ उदाहरण जो मैं वैज्ञानिक कोड के लिए लिखता हूं:

• समय इंटीग्रेटर्स के लिए, एक सटीक समाधान के साथ एक सरल ओडीई का उपयोग करें, और परीक्षण करें कि आपका इंटीग्रेटर किसी दिए गए सटीकता के भीतर हल करता है, और अलग-अलग चरण आकारों के साथ परीक्षण करके सटीकता का क्रम सही है।

• शून्य-स्थिरता परीक्षण: जांचें कि 0 बाउंड्री / प्रारंभिक शर्तों के साथ एक विधि 0 पर बनी हुई है।

• इंटरपोलेशन टेस्ट: एक रेखीय कार्य दिया, यह विश्वास दिलाता हूं कि एक प्रक्षेप सही है।

• विरासत सत्यापन: एक विरासत अनुप्रयोग में कोड का एक हिस्सा अलग करें जो सही होने के लिए पता है, और कुछ असतत मानों को परीक्षण के लिए उपयोग करने के लिए बाहर खींचते हैं।

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

Comments

क्या आप कृपया, स्पष्ट कर सकते हैं कि इंटरपोलेशन टेस्ट से आपका क्या मतलब है?

— दिमित्री कबानोव

Answer 1

निर्मित समाधान की विधि ।

शोधन अध्ययनों के माध्यम से सत्यापित करें कि विधि सटीकता के सैद्धांतिक आदेश को प्राप्त करती है।

उत्तर का संरक्षण। समाधानों के बिट-वार और मानक-वार प्रजनन।

Comments

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

— ऑरिलियस

@ ऑरेलियस: लेकिन यह परीक्षण-संचालित विकास के लिए एक शानदार रणनीति है! पीडीई / ओडीई / रैखिक बीजगणित कोड के लिए, आपको बहुत छोटे एमएमएस परीक्षण लिखने चाहिए जो एक सेकंड से भी कम समय में चल सकते हैं। जब आप कोई बदलाव करते हैं, तो आप उन्हें चलाते हैं। अगर वे टूटते हैं, तो आपने कुछ गलत किया है! आपको आश्चर्य होगा कि एक समस्या आपको (या जो भी) बता सकती है। $2\times 2\times 2$

— बिल बर्थ

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

— औरेलियस

@ यूरेलियस: यहाँ कोई तर्क नहीं है। आपके पास परीक्षणों की एक सीमा होनी चाहिए और उन सभी को अक्सर चलाना चाहिए।

— बिल बैर्थ

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

— हाइपरपैलियम

Answer 2

बिल ने पहले से ही कुछ तरीकों को सूचीबद्ध किया है जो आपकी चिंताओं को संबोधित करते हैं।

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

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

Comments

गुइडो के जवाब में जोड़ने के लिए, वह जिस अनुभव से बात करता है वह ~ 3,000 परीक्षणों में एन्कोडेड है जिसे हम प्रत्येक परिवर्तन के बाद deal.II पर चलाते हैं: dealii.org/developer/development/… । यदि आप सटीक उत्तर नहीं जानते हैं तो क्या करना है, इस सवाल पर: वैसे भी परीक्षण लिखें और आज के उत्तर की तुलना कल (या जब भी आपने परीक्षण लिखा हो) करें। किसी कोड के आउटपुट में परिवर्तन करने का एक तरीका मूल्यवान है, भले ही आपको पता न हो कि उन्होंने उत्तर को गलत बनाया है या पहले गलत उत्तर को सही किया है।

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

Answer 3

मुझे हाल ही में कम्प्यूटेशनल साइंस में टीडीडी पर यह थीसिस मिली। मैंने इसे अभी तक नहीं पढ़ा है इसलिए मुझे कोई पता नहीं है कि क्या यह कोई अच्छा है, लेकिन उम्मीद है कि यह कुछ मदद कर सकता है।

http://cyber.ua.edu/files/2014/12/u0015_0000001_0001551.pdf

Comments

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

— गोड्रिक सेर

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

— अलक्विमिस्ट