इकाई परीक्षण डिजाइन की सुविधा कैसे देते हैं?

43

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

यह डुप्लिकेट के रूप में आपके द्वारा चिह्नित प्रश्न के समान नहीं है, मैं वास्तविक उदाहरणों में रुचि रखता हूं कि यह कैसे मदद करता है, न कि केवल सिद्धांत "यह मदद करता है"। मुझे नीचे उत्तर और टिप्पणी पसंद है लेकिन मैं और सीखना चाहूंगा।

design unit-testing object-oriented-design

— User039402
स्रोत

7

क्या TDD

— gnat

3

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

— रॉबर्ट हार्वे

4

@gnat कर रही इकाई परीक्षण स्वचालित रूप से TDD का अर्थ नहीं लगाता है, यह एक अलग सवाल है

— Joppe

11

"इकाई परीक्षण (क्षेत्रों में मूल्यों को मान्य करना)" - आप इनपुट सत्यापन के साथ इकाई परीक्षणों को भ्रमित करते प्रतीत होते हैं।

— जोंशरशिपे

1

@jonrsharpe यह देखते हुए कि यह एक CSV फ़ाइल को पार्स कर रहा है, वह एक वास्तविक इकाई परीक्षण के बारे में बात कर सकता है जो एक निश्चित CSV स्ट्रिंग की पुष्टि करता है जो अपेक्षित आउटपुट देता है।

— जॉलीजोकर

3

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

लेखन-प्रथम परीक्षण प्रतिरूपकता और स्वच्छ कूट संरचना को संचालित करता है।

जब आप अपना कोड टेस्ट-पहले लिखते हैं, तो आप पाएंगे कि किसी दिए गए कोड की किसी भी "स्थिति" को स्वाभाविक रूप से निर्भरता (आमतौर पर मोक्स या स्टब्स के माध्यम से) से बाहर धकेल दिया जाता है जब आप उन्हें अपने कोड में मान लेते हैं।

"एक्स की स्थिति को देखते हुए, व्यवहार y की अपेक्षा करें," अक्सर आपूर्ति करने के लिए एक ठूंठ बन जाएगा x(जो एक ऐसा परिदृश्य है जिसमें परीक्षण को वर्तमान घटक के व्यवहार को सत्यापित करने की आवश्यकता है) और yएक नकली बन जाएगा, जिस पर एक कॉल सत्यापित की जाएगी परीक्षण का अंत (जब तक कि यह "वापस नहीं आना चाहिए y", जिस स्थिति में परीक्षण केवल वापसी मूल्य को स्पष्ट रूप से सत्यापित करेगा)।

फिर, एक बार जब यह इकाई निर्दिष्ट रूप में व्यवहार करती है, तो आप अपने द्वारा खोजे गए आश्रितों ( xऔर y) को लिखने के लिए आगे बढ़ते हैं ।

यह लेखन को स्वच्छ बनाता है, मॉड्यूलर कोड एक बहुत ही आसान और प्राकृतिक प्रक्रिया है, जहां अन्यथा अक्सर जिम्मेदारियों और युगल व्यवहार को एक साथ महसूस किए बिना धुंधला करना आसान होता है।

परीक्षण लिखना बाद में आपको बताएगा कि आपका कोड खराब तरीके से संरचित है।

जब कोड के टुकड़े के लिए परीक्षण लिखना मुश्किल हो जाता है क्योंकि स्टब या मॉक करने के लिए बहुत सी चीजें होती हैं, या क्योंकि चीजें बहुत कसकर एक साथ जोड़ दी जाती हैं, तो आप जानते हैं कि आपके कोड में सुधार करने के लिए आपके पास सुधार हैं।

जब "बदलते परीक्षण" एक बोझ बन जाते हैं क्योंकि एक एकल इकाई में बहुत सारे व्यवहार होते हैं, तो आप जानते हैं कि आपके कोड में सुधार करने के लिए आपके पास (या परीक्षण लिखने के लिए आपके दृष्टिकोण में - लेकिन यह आमतौर पर मेरे अनुभव में मामला नहीं है) ।

जब आपके परिदृश्य भी जटिल हो जाते हैं ( "अगर xऔर yऔर zफिर ...") क्योंकि आप अमूर्त अधिक की जरूरत है, आप जानते हैं कि आप अपने कोड में बनाने के लिए सुधार किया है।

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

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

— चींटी पी
स्रोत

@SSECommunity: आज तक केवल 2 अपवोट्स के साथ इस जवाब को अनदेखा करना बहुत आसान है। मैं माइकल फेदर्स द्वारा टॉक की अत्यधिक अनुशंसा करता हूं जिसे इस उत्तर में जोड़ा गया है।

— DISPLAYNAME

103

यूनिट परीक्षणों के बारे में महान बात यह है कि वे आपको अपने कोड का उपयोग करने की अनुमति देते हैं कि अन्य प्रोग्रामर आपके कोड का उपयोग कैसे करेंगे।

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

— Telastyn
स्रोत

7

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

— स्टीफन ब्रेन

41

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

— user949300

7

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

— तेलस्टिन

3

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

— jpmc26

2

@ user949300 - यहाँ जो क्लासिक उदाहरण मेरे मन में था वह एक रिपॉजिटरी का है जिसे एक कंस्ट्रक्शन की जरूरत है। मान लीजिए कि आप सार्वजनिक संपत्ति के रूप में इसे उजागर करते हैं, और आपको नया () रिपॉजिटरी करने के बाद इसे सेट करना होगा। विचार यह है कि 5 वीं या 6 वीं बार के बाद आपने एक परीक्षा लिखी है जो उस कदम को लेना भूल जाती है - और इस तरह दुर्घटनाग्रस्त हो जाती है- आप "स्वाभाविक रूप से" एक वर्ग के आक्रमणकारी होने के लिए मजबूर होने की ओर झुकेंगे - निर्माणकर्ता में उत्तीर्ण - जिससे आपका एपीआई बेहतर है और यह अधिक संभावना बनाता है कि उत्पादन कोड लिखा जा सकता है जो इस जाल से बचता है। यह कोई गारंटी नहीं है, लेकिन यह मदद करता है, imo है।

— स्टीफन ब्रेन

31

यह महसूस करने में मुझे काफी समय लग गया, लेकिन वास्तविक लाभ (संपादित करें: मेरे लिए, आपका दुस्साहस अलग-अलग हो सकता है) टेस्ट संचालित विकास ( यूनिट परीक्षणों का उपयोग करके ) यह है कि आपको एपीआई डिजाइन को सामने करना है !

विकास के लिए एक विशिष्ट दृष्टिकोण यह है कि किसी समस्या को कैसे हल किया जाए, और यह ज्ञान और प्रारंभिक कार्यान्वयन आपके समाधान को लागू करने का कोई तरीका है। यह कुछ बल्कि दिलचस्प परिणाम दे सकता है।

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

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

— थोरबजोरन रावन एंडरसन
स्रोत

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

— एंट पी

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

— जुआन मेंडेस

@AntP हाँ, यह एपीआई डिज़ाइन का हिस्सा है।

— Thorbjørn रावन एंडरसन

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

— Thorbjørn Ravn Andersen

@JuanMendes यदि आप अच्छे परीक्षण और छोटी इकाइयाँ लिख रहे हैं तो आप जिस प्रभाव का वर्णन कर रहे हैं, वह व्यवहार में किसी से छोटा नहीं है।

— एंट पी

6

मैं 100% सहमत हूँ कि इकाई परीक्षण "हमारे डिजाइन और रिफ्लेक्टर चीजों को परिष्कृत करने में हमारी मदद करता है"।

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

हालांकि, मेरे अनुभव में, पीढ़ीगत सरलीकृत इकाई परीक्षण, इससे पहले कि आप वास्तव में समझें कि डिज़ाइन क्या होना चाहिए, (संयोग से, यह हार्ड-कोर TDD का अतिशयोक्ति है, लेकिन अक्सर कोडर्स एक परीक्षा लिखते हैं इससे पहले कि वे बहुत सोचते हैं) अक्सर एनीमिक का नेतृत्व करते हैं डोमेन मॉडल जो बहुत सारे इंटर्नल को उजागर करते हैं।

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

— user949300
स्रोत

विधि मापदंडों की लंबी संख्या एक कोड गंध और एक डिजाइन दोष है।

— सूफियान

5

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

एक बार प्रोग्राम विकसित होने के बाद (यूनिट टेस्ट के साथ), क्योंकि बग्स को खुला रखा गया है, आप यह सुनिश्चित करने के लिए टेस्ट जोड़ सकते हैं कि बग्स ठीक हो गए हैं।

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

मैं अपने कुछ सहयोगियों की तुलना में थोड़ा ढीला हूं, क्योंकि मुझे परवाह नहीं है कि क्या कोड पहले लिखा गया है या परीक्षण पहले लिखा गया है।

— रॉबर्ट बैरन
स्रोत

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

— प्रयोक्ता ०३

5

जब आप अपने पार्सर को ठीक से परिसीमन करने वाले मान का पता लगाना चाहते हैं, तो आप इसे CSV फ़ाइल से एक पंक्ति पास करना चाहते हैं। अपने परीक्षण को प्रत्यक्ष और छोटा करने के लिए आप एक विधि के माध्यम से इसका परीक्षण करना चाहते हैं जो एक पंक्ति को स्वीकार करता है।

यह स्वचालित रूप से आपको व्यक्तिगत मान पढ़ने से लाइनों की रीडिंग को अलग कर देगा।

एक और स्तर पर आप अपने परीक्षण प्रोजेक्ट में सभी प्रकार की भौतिक CSV फाइलें नहीं रख सकते हैं, लेकिन कुछ अधिक पठनीय हैं, बस पठनीयता और परीक्षण के इरादे को बेहतर बनाने के लिए अपने परीक्षण के अंदर एक बड़े CSV स्ट्रिंग की घोषणा करें। इससे आप अपने पार्सर को किसी भी I / O से अलग कर सकते हैं, जिसे आप कहीं और करेंगे।

बस एक मूल उदाहरण, बस इसका अभ्यास करना शुरू करें, आपको कुछ बिंदु पर जादू महसूस होगा (मेरे पास)।

— Joppe
स्रोत

4

सीधे शब्दों में कहें, लेखन इकाई परीक्षण आपके कोड की खामियों को उजागर करने में मदद करते हैं।

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

उदाहरण के लिए: कैश कंप्‍यूटर से सामान निकालना शुरू करने पर विधि computeStuff ठीक से काम करता है, तो यह परीक्षण करना बहुत कठिन है। ऐसा इसलिए है क्योंकि आपको कैश को क्रैप को तब तक जोड़ना होगा जब तक कि "बिग कैश" लगभग पूरा न हो जाए।

public OopsIHardcoded {

   Cache cacheOfExpensiveComputations;

   OopsIHardcoded() {
       this.cacheOfExpensiveComputation = buildBigCache();
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

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

public HereIUseDI {

   Cache cacheOfExpensiveComputations;

   HereIUseDI(Cache cache) {
       this.cacheOfExpensiveComputation = cache;
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

इसी तरह के लाभ तब हो सकते हैं जब हमारे कोड को डेटा की आवश्यकता होती है जो आमतौर पर एक डेटाबेस में होता है ... बस आपको आवश्यक डेटा पास करें।

— इवान
स्रोत

2

ईमानदारी से, मुझे यकीन नहीं है कि आप उदाहरण का क्या मतलब है। कैसे विधि computeStuff कैश से संबंधित है?

— जॉन वी।

1

@ user970696 - हां, मैं यह कह रहा हूं कि "computeStuff ()" कैश का उपयोग करता है। सवाल यह है कि क्या हर समय (जो कि कैश की स्थिति पर निर्भर करता है) कंप्यूटर सही ढंग से काम करता है (नतीजतन,) यह पुष्टि करना कठिन है कि कंप्यूटर (जो आप सीधे सेट नहीं कर सकते हैं) कैश का निर्माण करें क्योंकि आपने "कैशऑफएक्सप्रेंसिवकंप्यूटेशन = बिल्डबीगचैचे ()" लाइन को हार्डकोड किया है; (कंस्ट्रक्टर के माध्यम से सीधे कैश में पास होने का विरोध)

— इवान

0

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

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

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

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

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

— topo Reinstate Monica
स्रोत

-2

जब नया कोड पुराने परीक्षणों में से सभी को पास कर लेता है, तो यूनिट परीक्षण पुन: निर्माण में मदद कर सकते हैं ।

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

बेशक इस काम को करने के लिए परीक्षणों को व्यापक होना चाहिए। मेरे उदाहरण में, आपके परीक्षण स्थिरता को कवर नहीं कर सकते हैं क्योंकि यह बुलबुले के साथ कोई चिंता नहीं थी।

— ओम
स्रोत

1

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

— एंट पी

@AntP, ओपी ने रिफैक्टिंग और यूनिट टेस्ट के बारे में पूछा।

— ओम

1

सवाल उल्लेख पुनर्रचना लेकिन वास्तविक सवाल यह है कि इकाई परीक्षण सुधार सकता / सत्यापित कोड डिजाइन के बारे में था - खुद पुनर्रचना की प्रक्रिया को आसान नहीं।

— एंट पी

-3

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

— डेविड बेकर
स्रोत

6

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

— हल्क