यूनिट परीक्षण गणितीय कोड

Question

मैं एक जटिल गणितीय सूत्र (एकीकरण और रूट खोज के लिए कॉमन्स-गणित पुस्तकालय का उपयोग करके) की गणना के लिए एक छोटी उपयोगिता लिख ​​रहा हूं। मैं इसे सामान्य व्यवसाय अनुप्रयोग के रूप में लिखने की कोशिश कर रहा था, हालांकि मुझे पता चला कि मुझे कक्षाओं की तेजी से बढ़ती संख्या मिल रही है। गणना के पहले चरण (2 इंटीग्रल के साथ 1 लाइन फॉर्मूला) प्राप्त करने के लिए, मैंने पहले से ही गणना के प्रत्येक छोटे बिट के लिए 3 कक्षाएं लिखी हैं, ताकि मैं निर्भरता इंजेक्शन का उपयोग कर सकूं और सभी कॉलों को कॉमन्स-गणित में ठीक से नकल कर सकूं। हालांकि यह नियंत्रण से बाहर हो रहा है, हालांकि, मैं एक समस्या के लिए 20 कक्षाओं के साथ समाप्त हो जाऊंगा जिसे एक वर्ग में (स्क्रीन परीक्षण के बिना) 2 स्क्रीन पर हल किया जा सकता है। आपका पसंदीदा दृष्टिकोण क्या होगा? मैं केवल इस के लिए स्वीकृति और उच्च स्तर के परीक्षणों पर भरोसा करने के लिए बहुत मोहक हूं।

Answer 1

परीक्षण को पूरी तरह से अनुपयोगी और समझने योग्य कोड बनाने की अनुमति न दें। और ऑब्जेक्ट उन्मुख दृष्टिकोण के साथ overengineer कार्यात्मक नहीं है।

आप एक फ़ंक्शन का परीक्षण कर रहे हैं, यानी स्टेटलेस जो एक ही तर्क के लिए एक ही परिणाम उत्पन्न करता है। और मुझे लगता है कि इस तरह आपको इसका परीक्षण करना चाहिए: इसे सभी संभावित समकक्ष वर्गों से तर्क दें और परिणाम पर जोर दें।

Answer 2

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

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

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

बेशक मानना ​​... यादृच्छिक समस्याओं को हल करना एक आसान समस्या है। कभी-कभी यह होता है, कभी-कभी यह नहीं होता है। बिना गणित कोड के बारे में हमें बताए बिना कहना मुश्किल है। अब ... क्या यह सभी मामलों को प्राप्त करता है? नहीं, लेकिन इसे "आम" मामले मिलेंगे। और यदि एक कोने का मामला अभ्यास में पॉप अप करता है, तो उसे यूनिट टेस्ट में लपेटें और इसे अपने कोड के अगले संस्करण में ठीक करें।