विकास के बाद परीक्षण के नुकसान क्या हैं?

Question

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

हालांकि बहस पर वे किसी भी तरह से अपने समान तरीके से कहते हैं।

कार्यान्वयन कोड पहले और यूनिट परीक्षण के बाद क्या संभावित समस्याएं उत्पन्न हो सकती हैं?

Answer 1

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

यदि यह पर्याप्त स्पष्ट नहीं है, तो परीक्षण पहले एफटीडब्ल्यू!

Answer 2

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

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

Answer 3

कार्यान्वयन से पहले परीक्षण हमेशा प्रोत्साहित किया जाता है। वास्तव में आपके सॉफ़्टवेयर में मौजूद बग को ठीक करने के अलावा, यह पता लगाने में सहायता करता है कि आपके कोड के बिट्स आवश्यक हैं क्योंकि एक इंजीनियर के पास 'कोड से अधिक' की प्रवृत्ति हो सकती है।

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