क्या यूनिट परीक्षणों में केवल 'कार्यात्मक' सॉफ़्टवेयर को कवर किया जाना चाहिए

9

हम एक नए सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में स्ट्रक्च्योर मैप का उपयोग कर रहे हैं । टीम के सदस्यों में से एक ने एक इकाई परीक्षण लागू किया है जो मूल रूप से स्ट्रक्च्योर मैप कंटेनर कॉन्फ़िगरेशन का परीक्षण करता है। यह निम्न कार्य करके करता है;

उन विधानसभाओं के उदाहरणों की संख्या की गणना करता है जो हमारे एप्लिकेशन नामस्थान में कक्षाओं के लिए कॉन्फ़िगर किए गए हैं।
वर्ग स्तर पर अपेक्षित उदाहरणों को परिभाषित करता है
ऐसे उदाहरण जो उम्मीद करते हैं कि कुल मिलाएँ उदाहरणों से मेल खाती हैं।
ऐसे उदाहरण जो उम्मीद करते हैं कि परीक्षण में परिभाषित उन लोगों से मेल खाते हैं

इसका एक उदाहरण है;

var repositories = container.GetAllInstances<IEnvironmentRepository>();
Assert.AreEqual(1, repositories .Count());
foundInstances = foundInstances + repositories .Count();

हमारे पास निम्न वर्ग के लिए 'यूनिट टेस्ट' भी हैं;

public MyClass(IEnvironmentRepository environmentRepository)
        {

        }

इन परीक्षणों में, हम IEnvironmentRepository का मजाक उड़ाते हैं, इसलिए इसे कंटेनर से इंजेक्ट नहीं किया जाएगा जैसा कि लाइव सिस्टम में होगा।

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

तो कई सवाल;

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

c# unit-testing

— ChrisBint
स्रोत

10

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

— जेरेन मोस्टर्ट

2

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

— क्रिसबिट

4

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

— जेरेन मोस्टर्ट

2

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

— फोशी

3

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

— फॉशी

13

यह पूरी तरह से मान्य स्वचालित परीक्षण है। मैं उन्हें "वास्तुकला परीक्षण" कहता हूं क्योंकि वे आपके कोड आधार के कंकाल घटकों की सुदृढ़ता को सत्यापित करते हैं।

क्या IoC कंटेनर अनुप्रयोग में सभी ऑब्जेक्ट पेड़ों को हल करने और बनाने में सक्षम है? क्या ऑटो मैपर अपने सभी पंजीकृत वस्तुओं के बीच बिना किसी असफलता के मानचित्र बना सकता है? क्या प्याज की वास्तुकला में केंद्रीय परत बाहरी कुछ भी नहीं है ?

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

चाहे वे यूनिट टेस्ट हैं ... शायद नहीं, लेकिन वे अभी भी अधिकांश भाग के लिए मेमोरी में काम करते हैं और बहुत तेज दौड़ते हैं। फिर, मुझे नहीं पता, ऐसा नहीं है कि यूनिट टेस्ट की सार्वभौमिक रूप से स्वीकृत परिभाषा थी।

— guillaume31
स्रोत

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

— क्रिसबिंट

6

इस तरह के परीक्षण के साथ समस्या यह है कि कार्यक्रम की आवश्यकता के बजाय इसके आंतरिक परीक्षण करें। क्या यह परीक्षण विफल हो सकता है भले ही कार्यक्रम आवश्यकतानुसार काम करता हो।

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

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

एक बेहतर स्वचालित परीक्षण कार्यक्रम को शुरू करने और यह देखने के लिए होगा कि क्या यह दुर्घटनाग्रस्त हो जाता है।

यूनिट परीक्षण के माध्यम से गिरने पर भी आपको एकीकरण या UI परीक्षण में इस प्रकार की त्रुटि को पकड़ना चाहिए।

कहा जाता है कि, कंटेनर सेटअप की बढ़ती जटिलता गधे में दर्द है। शायद कुछ 'खराब' परीक्षण इसके लायक हैं।

— ईवान
स्रोत

1

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

— रोबी डी
स्रोत

कॉन्फ़िगरेशन स्थिर है, यह पर्यावरण द्वारा संचालित नहीं है, कॉन्फ़िगरेशन में मौजूद सभी कक्षाएं उसी तरह सभी वातावरणों में उपयोग की जाएंगी। हां, जितने इंस्टेंसेस कॉन्फिग्रेशन में हो सकते हैं, उतने ही इंसांसेस इन कॉन्फिगरेशन से मेल खाने चाहिए, यह टेस्ट का हिस्सा है। जैसा कि मेरा उदाहरण दिखाया गया है, IEnvironmentRepository को हटाकर अन्य इकाई परीक्षणों को पारित करने की अनुमति दी गई है। विशिष्ट कंटेनर परीक्षण 2 एसेर्ट्स पर विफल रहा होगा; 1 - संभव आवृत्ति घोषणाओं की कुल संख्या मेल नहीं खाती, और 2 - IEnvironmentRepository के इंस्टेंसेस की विशिष्ट संख्या मेल नहीं खाएगी।

— क्रिसबिट

1

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

— रॉबी डे

2

यूनिट परीक्षणों को खटखटाने में 10 मिनट लगे। तैनाती में एक घंटे का समय लग सकता है।

— क्रिसबिंट

1

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

— क्रिसबिंट

1

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

— रॉबी डी

0

निर्भरता इंजेक्शन कंटेनर की जिम्मेदारी एक काम कर रहे अनुप्रयोग में विभिन्न मॉड्यूल को गोंद करना है ।

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

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

आपको एकीकरण परीक्षणों में सभी संभावित परीक्षण मामलों को कवर करने की आवश्यकता नहीं है, प्रति फीचर सिर्फ एक टेस्ट केस जो यूआई से डेटाबेस तक पूरा रास्ता कवर करता है।

यदि एकीकरण परीक्षण के मामले कुछ विशेष निर्भरता के तात्कालिकता को कवर नहीं करते हैं - आप बस ऐसे जोड़ते हैं।

एकीकरण परीक्षणों के साथ आप अपने कॉन्फ़िगरेशन के लिए पुन: लेखन इकाई परीक्षणों के बिना कंटेनरों को स्वतंत्र रूप से बदल सकते हैं।

— फैबियो
स्रोत

0

IMO, उत्तर हैं:

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

— इमर्सन कार्डसो
स्रोत

-1

यूनिटटेस्ट अलगाव में एक इकाई के वांछित व्यवहार को सत्यापित करता है ।

इसका मतलब यह है किसी भी तरह का विन्यास है नहीं के दायरे में UnitTests ।

फिर भी आपके पास अपने कॉन्फ़िगरेशन के लिए स्वचालित परीक्षण होना चाहिए, लेकिन ये यूनिटटेस्ट नहीं हैं ...

— टिमोथी ट्रक्सले
स्रोत

आपको इकाइयों की परिभाषा कहां से मिल रही है?

— क्रिसबिंट

मैं द आर्ट ऑफ़ यूनिटिंग में रॉय ओशेरोव का एक पसंद करता हूं : एक यूनिट ( उत्पादन- ) कोड का कोई भी हिस्सा है जो बदलने का एक ही कारण है। मैं अपनी दुनिया यह आमतौर पर एक एकल वर्ग से लेकर तीन या पाँच तक ...

— टिमोथी ट्रॉपल

यह उत्पादन कोड है जिसका परीक्षण किया जा रहा है।

— क्रिसबंट

बस नाइटपिकर्स को विचलित करना चाहता था , यह उम्मीद नहीं करता कि यह दूसरे तरीके से भी काम करता है ...; ओ)

— टिमोथी ट्रॉपल