रिफैक्टरिंग करते समय आप अपने यूनिट टेस्ट को कैसे काम करते हैं?

29

एक अन्य सवाल में, यह पता चला कि टीडीडी के साथ दर्द में से एक परीक्षण सूट को कोडैब के साथ और फिर से रिफैक्टरिंग के दौरान सिंक में रख रहा है।

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

रिफैक्टरिंग करते समय आप परीक्षण से कैसे बचते हैं?

क्या आप परीक्षण 'बेहतर' लिखते हैं? यदि हां, तो आपको क्या देखना चाहिए?
क्या आप कुछ प्रकार के रिफैक्टरिंग से बचते हैं?
क्या परीक्षण-रीफैक्टरिंग उपकरण हैं?

संपादित करें: मैंने एक नया प्रश्न लिखा था जिसमें पूछा गया था कि मेरा क्या मतलब है (लेकिन इसे एक दिलचस्प संस्करण के रूप में रखा गया है)।

development-process tdd refactoring

— एलेक्स फेनमैन
स्रोत

7

मैंने सोचा होगा कि, TDD के साथ, रिफैक्टरिंग में आपका पहला कदम एक परीक्षण लिखना है जो विफल हो जाता है और फिर इसे काम करने के लिए कोड को रिफलेक्टर करता है।

— मैट एलेन

क्या आपकी आईडीई यह पता नहीं लगा सकती है कि परीक्षणों को भी कैसे रिफलेक्टर करना है?

@ Thorbjørn रावन एंडरसन, हाँ, और मैंने एक नया प्रश्न लिखा, जिसमें पूछा गया था कि मेरा क्या मतलब है (लेकिन इसे एक दिलचस्प संस्करण के रूप में रखा गया है; देखें अज़ेगलोव का जवाब, जो अनिवार्य रूप से आप कहते हैं, वह देखें)

— एलेक्स फीमिन

इस प्रश्न पर थार जानकारी जोड़ने पर विचार किया?

35

आप जो करने की कोशिश कर रहे हैं, वह वास्तव में रिफैक्टिंग नहीं है। परावर्तन के साथ, परिभाषा के अनुसार, आप अपना सॉफ़्टवेयर क्या नहीं बदलते हैं , आप इसे कैसे बदलते हैं ।

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

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

— azheglov
स्रोत

7

समान कोड X ने 15 स्थानों की नकल की। प्रत्येक स्थान पर अनुकूलित। आप इसे एक सामान्य पुस्तकालय बनाते हैं और इन अंतरों की अनुमति देने के लिए एक्स या पैरामीटर का उपयोग करते हैं। मैं गारंटी देता हूं कि X के लिए यूनिट परीक्षण विफल हो जाएंगे। X के ग्राहक विफल हो जाएंगे क्योंकि सार्वजनिक इंटरफ़ेस थोड़ा बदल जाता है। रिडिजाइन या रिफ्लेक्टर? मैं इसे रिफ्लेक्टर कहता हूं लेकिन किसी भी तरह से यह सभी तरह की चीजों को तोड़ देता है। लब्बोलुआब यह है कि आप तब तक रिफ्लेक्टर नहीं कर सकते, जब तक आप यह नहीं जानते कि यह सब एक साथ कैसे फिट बैठता है। फिर परीक्षणों को ठीक करना थकाऊ लेकिन अंततः तुच्छ है।

— केविन

3

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

— otto

3

@ केविन: मेरा मानना है कि आप जो वर्णन करते हैं वह एक नया स्वरूप है, क्योंकि सार्वजनिक इंटरफ़ेस बदल जाता है। फाउलर की रिफैक्टिंग की परिभाषा ("बाह्य व्यवहार को बदलने के बिना कोड की आंतरिक संरचना में फेरबदल करना") इस बारे में काफी स्पष्ट है।

— अज़ेगलोव

3

@azheglov: शायद लेकिन मेरे अनुभव में अगर कार्यान्वयन खराब है तो इंटरफ़ेस है

— केविन

2

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

— डिर्क बोअर

21

यूनिट टेस्ट होने के फायदों में से एक यह है कि आप आत्मविश्वास से रिफ्लेक्टर कर सकते हैं।

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

यदि रिफैक्टरिंग सार्वजनिक इंटरफ़ेस को बदलता है तो परीक्षणों को फिर से लिखा जाना चाहिए। नए परीक्षण पास होने तक रिफ्लेक्टर।

मैं किसी भी रिफैक्टिंग से कभी नहीं बचूंगा क्योंकि यह परीक्षणों को तोड़ता है। यूनिट टेस्ट लिखना एक बट में दर्द हो सकता है लेकिन लंबे समय में दर्द के लायक है।

— टिम मर्फी
स्रोत

7

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

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

अगर मैं अपने निजी या संरक्षित सदस्यों (हम "दोस्त" को विज़ुअल बेसिक में एक्सपोज़ करके अपने SUT की आंतरिक स्थिति की जाँच कर रहा हूँ, या एक्सेस लेवल "इंटरनल" को बढ़ा सकता है और c # में "internalsvanishto" का उपयोग कर सकता है;) कई OO भाषाओं में; c # एक " परीक्षण-विशिष्ट-उपवर्ग " का उपयोग किया जा सकता है) फिर अचानक कक्षा की आंतरिक स्थिति मायने रखेगी - आप कक्षा को एक ब्लैक बॉक्स के रूप में फिर से तैयार कर सकते हैं, लेकिन सफेद बॉक्स परीक्षण विफल हो जाएंगे। मान लीजिए कि किसी एकल फ़ील्ड का पुन: उपयोग किया जाता है, तो अलग-अलग चीजों का मतलब है (अच्छा अभ्यास नहीं!) जब SUT स्थिति बदलता है - अगर हम इसे दो क्षेत्रों में विभाजित करते हैं, तो हमें टूटे हुए परीक्षणों को फिर से लिखना पड़ सकता है।

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

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

तो SUT के अंतरंग आंतरिक विवरण के परीक्षणों को युग्मित होने से रोकने के लिए इसे करने में मदद मिल सकती है:

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

उपरोक्त सभी बिंदु परीक्षणों में उपयोग किए गए सफेद-बॉक्स युग्मन के उदाहरण हैं। तो पूरी तरह से टूटने वाले परीक्षण से बचने के लिए, SUT के ब्लैक-बॉक्स परीक्षण का उपयोग करें।

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

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

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

[...]

कार्यान्वयन के लिए युग्मन भी रिफैक्टिंग के साथ हस्तक्षेप करता है, क्योंकि कार्यान्वयन परिवर्तन क्लासिक परीक्षण की तुलना में परीक्षणों को तोड़ने की अधिक संभावना है।

फाउलर - मोक्स स्टब्स नहीं हैं

— पूर्णतावादी
स्रोत

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

— परफेक्शनिस्ट

5

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

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

— फ्रैंक शायर
स्रोत

क्या होगा अगर वह परीक्षणों द्वारा परीक्षण की गई विधि का नाम बदल दे? जब तक आप परीक्षणों में भी उनका नाम नहीं बदल लेते, परीक्षण विफल हो जाएंगे। यहाँ वह कार्यक्रम का व्यवहार नहीं बदल रहा है।

— ऑस्कर मेडरोस

2

जिस स्थिति में उसके परीक्षण भी रद्द किए जा रहे हैं। हालांकि आपको सावधान रहने की जरूरत है: पहले आप विधि का नाम बदलें, फिर आप अपना परीक्षण चलाएं। यह सही कारणों से विफल होना चाहिए (यह संकलन नहीं कर सकता (C #), आपको एक MessageNotUnderstood अपवाद (स्मालटाक) मिलता है, ऐसा कुछ भी नहीं लगता है (Objective-C का अशक्त भोजन)। फिर आप अपना परीक्षण बदलते हैं, यह जानकर कि आपने गलती से कोई बग नहीं पेश किया है। "यदि आपके परीक्षण टूट जाते हैं" का अर्थ है "यदि आपके परीक्षण के बाद आपके परीक्षण टूटते हैं, तो दूसरे शब्दों में"। बदलाव को छोटा रखने की कोशिश करें!

— फ्रैंक शीयर

1

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

— क्रिस्टियन एच।

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

— कोला

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

— फ्रैंक शीयर

4

मुझे लगता है कि इस सवाल के साथ परेशानी यह है कि अलग-अलग लोग 'रिफैक्टिंग' शब्द को अलग तरीके से ले रहे हैं। मुझे लगता है कि आपके द्वारा की जाने वाली कुछ चीजों को ध्यान से परिभाषित करना सबसे अच्छा है:

>  Keep the API the same, but change how the API is implemented internally
>  Change the API

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

लेकिन यह बहुत स्पष्ट है। तो आप केवल refactoring से मतलब है, कि आप एपीआई बदल रहे हैं।

तो मुझे जवाब दो कि कैसे दृष्टिकोण करने के लिए!

पहले एक नया एपीआई बनाएं, वही करें जो आप चाहते हैं कि आपका नया एपीआई व्यवहार हो। यदि ऐसा होता है कि इस नए एपीआई का एक नाम OLDER API है, तो मैं नए API नाम में _NEW नाम जोड़ता हूं।

int DoSomethingInterestingAPI ();

हो जाता है:

int DoSomethingInterestingAPI_NEW( int takes_more_arguments );
int DoSomethingInterestingAPI_OLD();
int DoSomethingInterestingAPI() { DoSomethingInterestingAPI_NEW (whatever_default_mimics_the_old_API);

ठीक है - इस स्तर पर - आपके सभी प्रतिगमन परीक्षण sill पास - DoSomethingInterestingAPI () नाम का उपयोग कर रहे हैं।

अगले, अपने कोड के माध्यम से जाओ और DoSomethingInterestingAPI () DoSomethingInterestingAPI_NEW () के उचित संस्करण के लिए सभी कॉल बदल। इसमें नई एपीआई का उपयोग करने के लिए आपके प्रतिगमन परीक्षणों के कुछ हिस्सों को अद्यतन / पुनर्लेखन करना शामिल है।

अगला, [[पदावनत ()]] के रूप में DoSomethingInterestingAPI_OLD () को चिह्नित करें। जब तक आप पसंद करते हैं तब तक अपग्रेड किए गए एपीआई के आसपास रहें (जब तक कि आपने सुरक्षित रूप से सभी कोड को अपडेट नहीं किया है जो उस पर निर्भर हो सकता है)।

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

— लुईस प्रिंगल
स्रोत

मुझे यह उत्तर पसंद है क्योंकि यह स्पष्ट करता है कि SUT को यूनिट टेस्ट एक प्रकाशित Api के बाहरी क्लाइंट के समान है। आप जो लिखते हैं, वह 'निर्भरता नरक' से बचने के लिए प्रकाशित पुस्तकालय / घटक को प्रबंधित करने के लिए सेम वीर प्रोटोकॉल के समान है। यह हालांकि समय और लचीलेपन की लागत पर आता है, इस दृष्टिकोण को हर माइक्रो यूनिट के सार्वजनिक इंटरफ़ेस के लिए एक्सट्रपलेट करने का मतलब है एक्सट्रपलेशन लागत भी। एक अधिक लचीला तरीका यह है कि परीक्षण से जितना संभव हो सके परीक्षणों को अलग किया जाए, परीक्षण इनपुट और आउटपुट का वर्णन करने के लिए एकीकरण परीक्षण या एक अलग DSL

— KolA

1

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

यदि आप इकाई परीक्षण करना चाहते हैं जो प्रत्येक विधि का परीक्षण करता है, तो उसी समय उन्हें फिर से चालू करने की अपेक्षा करें।

— gbjbaanb
स्रोत

1

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

— कोला

1

रिफैक्टरिंग के दौरान और बाद में कोडबेस के साथ तालमेल रखने के लिए

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

परिभाषा के अनुसार "इकाइयां" निम्न-स्तरीय कार्यान्वयन विवरण हैं, इकाइयों का इंटरफ़ेस / विभाजन / मर्ज को बदल सकता है और अन्यथा सिस्टम के रूप में परिवर्तित होता है। यूनिट परीक्षणों की प्रचुरता वास्तव में इस विकास में बाधा डालती है जितना कि यह मदद करता है।

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

— कोला
स्रोत

0

आपके परीक्षणों को कार्यान्वयन के लिए बहुत कसकर जोड़ा गया है और आवश्यकता नहीं है।

इस तरह की टिप्पणियों के साथ अपने परीक्षण लिखने पर विचार करें:

//given something
...test code...
//and something else
...test code...
//when something happens
...test code...
//then the state should be...
...test code...

इस तरह आप परीक्षणों से अर्थ नहीं निकाल सकते।

— mcintyre321
स्रोत