आप नियंत्रकों के लिए यूनिट-परीक्षण क्यों लिखेंगे?

Question

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

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}

Comments

यूनिट टेस्टिंग एप्लिकेशन लॉजिक और डिस्ट्रेस्टिंग लैंग्वेज कंस्ट्रक्शन के बीच लाइन

— gnat

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

— मार्जन वेनमा

stackoverflow.com/q/8818207/5934037

— Laiv

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

— 10

Answer 1

वे मुख्य बिंदु यहाँ है:

मैं पूरी तरह से अच्छी तरह से जानता हूं कि अगर यह नियंत्रक किसी ब्राउज़र में विधि को निष्पादित करके वांछित प्रकार लौटाता है

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

संपादित करें: @anotherdave टिप्पणी जोड़ना:

यह स्केलिंग में आसानी के बारे में है। एक ब्राउज़र में एक नियंत्रक का परीक्षण करना ठीक हो सकता है; 10, 20, 50 नियंत्रकों के बारे में क्या? आप एक बार परीक्षण लिखेंगे; कंट्रोलर बदलने पर आपको इसे अपडेट करने की आवश्यकता हो सकती है, जो ओवरहेड है। लेकिन आप कितनी बार तैनात करते हैं? निश्चित रूप से हर बार एक मैनुअल जाँच करें कि परीक्षण में बहुत अधिक ओवरहेड है

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

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

Comments

पुनः जोड़ने के लिए: I would know perfectly well if this controller returned the wanted type by executing the method in a browser.- यह स्केलिंग में आसानी के बारे में है। एक ब्राउज़र में एक नियंत्रक का परीक्षण करना ठीक हो सकता है; 10, 20, 50 नियंत्रकों के बारे में क्या? आप एक बार परीक्षण लिखेंगे; कंट्रोलर बदलने पर आपको इसे अपडेट करने की आवश्यकता हो सकती है, जो ओवरहेड है। लेकिन आप कितनी बार तैनात करते हैं ? निश्चित रूप से हर बार एक मैनुअल जाँच करें कि परीक्षण में बहुत अधिक ओवरहेड है।

— anotherdave

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

— अरोठ

@anotherdave टिप्पणी जोड़ा गया

— Walfrat

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

— वॉल्फ्रैट

Answer 2

आप नियंत्रकों के लिए यूनिट-परीक्षण क्यों लिखेंगे?

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

• नियंत्रक में जटिल सेवा वायरिंग तर्क हो सकता है, जो त्रुटि-प्रवण है। सेवाएं स्वयं ठीक काम कर सकती हैं यह वह परिणाम है जिसे आप परीक्षण करना चाहते हैं और किसी कारण से आपने अपने ऐप में ऑर्केस्ट्रेशन लेयर को पेश नहीं करने का विचार किया
• आपके नियंत्रकों में एप्लिकेशन और नियंत्रक के पूरे बड़बोले तर्क मौजूद हैं, जो वास्तव में आप परीक्षण कर सकते हैं (कृपया इस बात का ढोंग न करें कि आपका सारा जीवन आपने आदर्श कोडबेस के साथ काम किया है, ऐसे कोडबेस हैं, मेरा विश्वास करो)
• आपकी टीम में 99% जीनियस और 1% औसत लोग हैं और आप उस 1% को अपने वेतन में रखना चाहते हैं

Comments

मैं जोड़ता हूं: "आप भविष्य में इस बात से दूर नहीं रह सकते कि कौन परियोजना से छुटकारा पाने जा रहा है, और परीक्षण स्व-दस्तावेज कोड का हिस्सा हैं"

— Laiv

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

— वेन कॉनराड

Answer 3

मैं ओपी से पूरी तरह सहमत हूं।

एक नियंत्रक के लिए एक इकाई परीक्षण व्यर्थ है। आप प्रतिगमन परीक्षणों (उदाहरण के लिए सेलेनियम का उपयोग करके) के माध्यम से अपने नियंत्रकों का परीक्षण करते हैं।

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

Comments

शायद ऐसा है, लेकिन यह सवाल का जवाब नहीं है। वास्तव में, यह यहां यूनिट परीक्षणों के उपयोग के खिलाफ एक तर्क है।

— J --Mᴇᴇ

मुझे लगता है कि मैंने इस सवाल का जवाब दिया "क्या आपको लगता है कि इसके लिए एक परीक्षा की आवश्यकता है और क्यों?"

— विंकब्रेस

हां, मुझे लगता है कि @winkbrace और मैं इस पर समान विचार साझा करते हैं। लेकिन मेरा यह भी मानना ​​है कि यह इस बारे में चर्चा है कि आपको इकाई परीक्षण क्या करना चाहिए और क्या नहीं। मुझे लगता है कि लोग बहुत अधिक और "गलत" चीजों का परीक्षण करते हैं। मेरे उदाहरण में, नियंत्रक का परीक्षण बहुत कम मूल्य देता है क्योंकि यह बहुत पतला है और उम्मीद है कि सेवाओं के आसपास परीक्षण हैं। यहां सभी उत्तर सार्थक हैं और अच्छे अंक हैं, लेकिन सही उत्तर के रूप में किसी एक को चिह्नित करना वास्तव में संभव नहीं है।

— फ्रॉस्टिंग्स

अलग-अलग घटकों के लिए यूनिट परीक्षणों से स्वचालित एकीकरण परीक्षण, अलग और अलग का उपयोग करके नियंत्रक तर्क का परीक्षण किया जा सकता है।

— KevBurnsJr

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

— रासना