क्या कोई कारण है कि परीक्षण उस कोड के साथ इनलाइन नहीं लिखे गए हैं जो वे परीक्षण करते हैं?

91

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

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

— क्रिस Devereux
स्रोत

33

कुछ प्रोग्रामिंग लैंग्वेज जैसे अजगर सिद्धांत के साथ आपको ऐसा करने की अनुमति देता है।

— सिमोन बर्गोट

2

आप महसूस कर सकते हैं कि बीडीडी-शैली चश्मा कोड को समझाने में गद्य से बेहतर हैं, लेकिन इसका मतलब यह नहीं है कि दोनों का संयोजन बेहतर नहीं है।

— जेएफओ

5

यहाँ आधे तर्क इनलाइन डॉक्यूमेंटेशन पर भी लागू होते हैं।

— कोडइन्चोस

3

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

7

अनुबंध द्वारा डिजाइन इनलाइन विनिर्देशों के लिए अनुमति देता है जो परीक्षण को सीधा बनाते हैं।

— फ्यूहरमैनटर

89

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

हालाँकि, इनलाइन परीक्षण में कई स्पष्ट कमियाँ हैं:

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

— vaughandroid
स्रोत

9

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

— क्रिस डेवर्क्स

2

इन पंक्तियों के साथ, यह संभव है (और शायद वांछनीय) एक व्यक्ति को परीक्षण बनाने के लिए और दूसरा वास्तव में कोड को लागू करना। परीक्षणों को इनलाइन करना कठिन बना देता है।

— जिम नट

6

अगर मैं कर सकता नीचे downvote। यह किसी भी तरह से एक जवाब कैसे है? कार्यान्वयन करने वाले परीक्षण नहीं लिख रहे हैं? यदि वे कार्यान्वयन विवरणों को देखते हैं तो लोग परीक्षण छोड़ देते हैं? "बस बहुत मुश्किल" बड़ी फ़ाइलों पर संघर्ष ?? एएनडी कैसे किसी भी तरह से एक परीक्षण कार्यान्वयन कार्यान्वयन के साथ भ्रमित हो सकता है ???

— bharal

5

@bharal इसके अलावा, "बस बहुत कठिन" के लिए, मर्दवाद एक मूर्खता का गुण है। मैं चाहता हूं कि जिस समस्या को मैं वास्तव में हल करने की कोशिश कर रहा हूं, उसे छोड़कर सब कुछ आसान हो।

— डेवॉर्ड

3

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

— स्टीव ३१

36

मैं कुछ सोच सकता हूँ:

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

अब इनमें से प्रत्येक मुद्दे के लिए संभावित समाधान हैं। लेकिन IMO, पहली जगह में वहाँ नहीं जाना सरल है।

यह देखने योग्य है कि शुरुआती दिनों में, जावा प्रोग्रामर इस तरह का काम करते थे; उदाहरण के main(...)लिए परीक्षण की सुविधा के लिए कक्षा में एक विधि भी शामिल है । यह विचार लगभग पूरी तरह से गायब हो गया है। किसी प्रकार के परीक्षण ढांचे का उपयोग करके परीक्षणों को अलग से लागू करना उद्योग अभ्यास है।

यह भी देखने योग्य है कि साफ्टवेयर इंजीनियरिंग उद्योग में लिटरेट प्रोग्रामिंग (जैसा कि नथ द्वारा कल्पना की गई है) ने कभी नहीं पकड़ा है।

— स्टीफन सी
स्रोत

4

+1 पठनीयता संबंधी समस्याएं - परीक्षण कोड कार्यान्वयन कोड के लिए आनुपातिक रूप से अधिक हो सकता है, विशेष रूप से ओओ डिजाइनों में।

— फूहरमैनटर

2

टेस्ट चौखटे का उपयोग करके इंगित करने के लिए +1। मैं उत्पादन कोड के साथ समवर्ती रूप से एक अच्छे परीक्षण ढांचे का उपयोग करने की कल्पना नहीं कर सकता।

— joshin4colours

1

पुन: आप अपने ग्राहकों / ग्राहकों को अपना परीक्षण कोड नहीं देखना चाहेंगे। (मुझे यह कारण पसंद नहीं है ... लेकिन यदि आप एक बंद स्रोत परियोजना पर काम कर रहे हैं, तो परीक्षण कोड ग्राहक की किसी भी तरह से मदद करने की संभावना नहीं है।) - यह क्लाइंट मशीन पर परीक्षण चलाने के लिए वांछनीय हो सकता है। परीक्षणों को चलाने से यह पता लगाने में मदद मिल सकती है कि समस्या क्या है और ग्राहकों में अंतर को पहचानने के लिए क्या है ..

— sixtyfootersdude

1

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

— स्टीफन C

1

1) क्या आपने मेरे उत्तर के पहले भाग को याद किया है जहाँ मैंने तीन वास्तविक कारण दिए हैं? वहाँ कुछ "महत्वपूर्ण विचार" शामिल थे .... 2) क्या आपने दूसरा भाग याद किया जहां मैंने कहा था कि जावा प्रोग्रामर ऐसा करते थे, लेकिन वे अब नहीं करते हैं? और स्पष्ट निहितार्थ कि प्रोग्रामर ने ऐसा करना बंद कर दिया ... अच्छे कारण के लिए?

— स्टीफन C

14

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

माइकल फेदर्स ने इस बारे में एक प्रस्तुति दी है और यह उन कई तरीकों में से एक है जिसका वह उल्लेख करता है कि आप कोड की गुणवत्ता में सुधार कर सकते हैं।

— डैनियल कपलान
स्रोत

13

अपने कोड में कक्षाओं के बीच तंग युग्मन से बचने की कोशिश करने वाले कई कारणों से, परीक्षणों और कोड के बीच अनावश्यक युग्मन से बचना भी एक अच्छा विचार है।

निर्माण: टेस्ट और कोड अलग-अलग समय पर, अलग-अलग लोगों द्वारा लिखे जा सकते हैं।

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

पुन: प्रयोज्य: यदि आप परीक्षण इनलाइन डालते हैं, तो आप उन्हें कोड के किसी अन्य टुकड़े के साथ उपयोग नहीं कर सकते।

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

चयन क्षमता: परीक्षणों को कोड से अलग रखने से यह चुनना आसान हो जाता है कि आप कौन से परीक्षण चलाना चाहते हैं।

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

— कालेब
स्रोत

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

— एंड्रेस एफ

1

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

— कालेब

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

— user1852503

10

यहां कुछ अतिरिक्त कारण दिए गए हैं जिनके बारे में मैं सोच सकता हूं:

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

— डॉक्टर ब्राउन
स्रोत

5

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

— mhr
स्रोत

9

असंभव नहीं। इसके लिए एक अतिरिक्त प्रीप्रोसेसिंग चरण की आवश्यकता होगी, जैसा कि एलपी करता है। उदाहरण के लिए C, या संकलन-दर-भाषा भाषा में यह आसानी से किया जा सकता है।

— क्रिस डेवेरेक्स

मुझे इंगित करने के लिए +1। मैंने अपना उत्तर संपादित कर दिया है।

— mhr

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

— zumalifeguard

5

यह विचार एक वस्तु-आधारित या वस्तु-उन्मुख डिजाइन के संदर्भ में "Self_Test" पद्धति पर निर्भर करता है। यदि Ada जैसी संकलित वस्तु-आधारित भाषा का उपयोग किया जाता है, तो सभी आत्म-परीक्षण कोड को कंपाइलर द्वारा उत्पादन संकलन के दौरान अप्रयुक्त (कभी भी आमंत्रित नहीं) के रूप में चिह्नित किया जाएगा, और इसलिए यह सभी दूर हो जाएगा - इसमें से कोई भी दिखाई नहीं देगा। परिणामी निष्पादन योग्य।

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

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

उचित प्रोग्रामिंग लैंग्वेज सपोर्ट के अभाव में, इसका सबसे अच्छा तरीका यह है कि साथी ऑब्जेक्ट बनाया जाए। दूसरे शब्दों में, आपके द्वारा कोड की गई प्रत्येक वस्तु के लिए (चलो इसे "Big_Object" कहते हैं), आप एक दूसरा, साथी ऑब्जेक्ट भी बनाते हैं, जिसके नाम में "वास्तविक" ऑब्जेक्ट के नाम के साथ एक मानक प्रत्यय होता है (इस मामले में, "Big_Object_Self_Test) "), और जिनके विनिर्देशन में एक ही विधि शामिल है (" Big_Object_Self_Test.Self_Test (This_Big_Object: Big_Object) बूलियन लौटाएं ")। साथी ऑब्जेक्ट तब मुख्य ऑब्जेक्ट के विनिर्देश पर निर्भर करेगा, और कंपाइलर साथी विनिर्देश के कार्यान्वयन के खिलाफ उस विनिर्देश के सभी अनुशासन को पूरी तरह से लागू करेगा।

— commenter8
स्रोत

4

यह बड़ी संख्या में टिप्पणियों के जवाब में है, जिसमें कहा गया है कि इनलाइन परीक्षण नहीं किए गए हैं, क्योंकि परीक्षण कोड को हार्ड कॉपी से निकालना असंभव है। यह असत्य है। लगभग सभी संकलक और संयोजनकर्ता पहले से ही संकलित भाषाओं, जैसे कि C, C ++, C # के साथ इसका समर्थन करते हैं, इसे संकलक निर्देशों के साथ किया जाता है।

सी # के मामले में (मेरा मानना है कि सी ++ के साथ-साथ, सिंटैक्स आपके द्वारा उपयोग किए जा रहे कंपाइलर के आधार पर थोड़ा अलग हो सकता है) यह है कि आप इसे कैसे कर सकते हैं।

#define DEBUG //  = true if c++ code
#define TEST /* can also be defined in the make file for c++ or project file for c# and applies to all associated .cs/.cpp files */

//somewhere in your code
#if DEBUG
// debug only code
#elif TEST
// test only code
#endif

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

— जॉन
स्रोत

2

हम अपने पर्ल कोड के साथ इनलाइन परीक्षणों का उपयोग करते हैं। एक मॉड्यूल है, टेस्ट :: इनलाइन , जो इनलाइन कोड से टेस्ट फाइल उत्पन्न करता है।

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

कुछ चिंताओं के जवाब में:

इनलाइन परीक्षण POD अनुभागों में लिखे गए हैं, इसलिए वे वास्तविक कोड का हिस्सा नहीं हैं। उन्हें दुभाषिया द्वारा अनदेखा किया जाता है, इसलिए कोई कोड ब्लोट नहीं है।
हम परीक्षण वर्गों को छिपाने के लिए विम तह का उपयोग करते हैं। केवल एक चीज जिसे आप देख रहे हैं, प्रत्येक विधि के ऊपर एक एकल पंक्ति है जैसे परीक्षण किया जा रहा है +-- 33 lines: #test----। जब आप परीक्षण के साथ काम करना चाहते हैं, तो आप इसका विस्तार करते हैं।
टेस्ट :: इनलाइन मॉड्यूल सामान्य TAP- संगत फ़ाइलों के लिए परीक्षणों का "संकलन" करता है, इसलिए वे पारंपरिक परीक्षणों के साथ सह-अस्तित्व में हो सकते हैं।

सन्दर्भ के लिए:

— विधायक
स्रोत

1

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

— मार्क रेंडले
स्रोत

1

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

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

— हंस-पीटर स्टॉर
स्रोत

0

यह सच नहीं है। अपनी यूनिट-परीक्षणों को उत्पादन कोड के साथ रखना बेहतर होता है जब उत्पादन कोड विशेष रूप से तब होता है जब उत्पादन दिनचर्या शुद्ध होती है।

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

— zumalifeguard
स्रोत