यूनिट परीक्षण पर्याप्त नहीं है। स्थिर टाइपिंग की आवश्यकता है!

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

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

उनके तर्क का सार इस प्रकार है:

1. स्टेटिक टाइपिंग बग का पता लगाने के लिए पर्याप्त नहीं है, इसलिए यूनिट परीक्षणों की आवश्यकता है;
2. आपके पास परीक्षण होने के बाद स्टैटिक टाइपिंग बेमानी हो जाती है;
3. स्थैतिक टाइपिंग के कारण, कुछ सही कार्यक्रम संकलन चरण में चेतावनी उत्पन्न कर सकते हैं।

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


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

प्रयोग शुरू करने से पहले, काम करने के लिए गतिशील और स्थिर टाइपिंग वाली भाषाओं को चुनना आवश्यक था।

एक गतिशील भाषा के मानदंड निम्नानुसार थे:

1. इस भाषा को गतिशील रूप से टाइप किया जाना चाहिए;
2. भाषा को इकाई परीक्षण का समर्थन करना चाहिए;
3. इस भाषा में पर्याप्त संख्या में ओपनसोर्स समाधान की आवश्यकता है;
4. भाषा को अच्छी तरह से जाना जाना चाहिए और समर्थकों की पर्याप्त संख्या होनी चाहिए।

इन मानदंडों के लिए पायथन महान है।

इसके बाद, एक स्थिर भाषा का चयन करना आवश्यक था जो कई आवश्यकताओं को ध्यान में रखती है:

1. भाषा को पायथन के समान प्लेटफॉर्म पर चलना चाहिए;
2. भाषा में एक सख्त टंकण होना चाहिए;
3. स्थैतिक टाइपिंग के समर्थकों द्वारा भाषा का सम्मान किया जाना चाहिए।

हास्केल ने इन सभी आवश्यकताओं को पूरा किया।

इसके बाद, मैंने चार यादृच्छिक परियोजनाओं का चयन किया, जिन्हें पायथन से हास्केल: द पायथन एनएमईए टूलकिट , मिडीयूटिल , ग्रेपफ्रूट और पायफोंटइंफो में प्रसारित किया जाना था ।

पायथन NMEA टूलकिट

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

MIDIUtil

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

चकोतरा

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

PyFontInfo

PyFontInfo से अनुवाद ने 6 प्रकार की त्रुटियों की पहचान की। स्थिर रनिंग का उपयोग करके दो रनटाइम त्रुटियों को हल किया जा सकता है। एक टेस्ट को खत्म किया जा सकता है। PyFontInfo भी struct.pack और struct.unpack का उपयोग करता है, इसलिए इसे Haskell में अनुवादित नहीं किया जा सकता है, लेकिन इस सीमा को दरकिनार किया जा सकता है।

परिणाम

अनुभव से पता चला है कि बिना किसी कठिनाई के सभी परियोजनाओं का स्थैतिक रूप से अनुकूलन के साथ एक भाषा में अनुवाद किया जा सकता है, और परिवर्तन न्यूनतम होंगे। यह पता चला कि इकाई परीक्षण को स्थैतिक टाइपिंग के लिए पर्याप्त प्रतिस्थापन नहीं कहा जा सकता है। प्रयोग के दौरान, 17 टाइपिंग त्रुटियों का पता लगाया गया था जो परीक्षणों द्वारा पता नहीं लगाए गए थे; लेकिन कई त्रुटियों को अभी भी परीक्षणों द्वारा कवर किया गया था।

निष्कर्ष

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