Runtime: यूनिट परीक्षणों के लिए httpClient.GetAsync(..) विधि का उपहास करने का एक आसान तरीका?

HttpClient एक अन्य HTTP पुस्तकालय पर एक अमूर्त परत से ज्यादा कुछ नहीं है। इसके प्राथमिक उद्देश्यों में से एक आपको व्यवहार (कार्यान्वयन) को बदलने की अनुमति दे रहा है, जिसमें नियतात्मक इकाई परीक्षण बनाने की क्षमता शामिल है, लेकिन इतनी ही सीमित नहीं है।

अन्य कार्यों में, HttpClient स्वयं "वास्तविक" और "नकली" ऑब्जेक्ट दोनों के रूप में कार्य करता है, और HttpMessageHandler वह है जिसे आप अपने कोड की जरूरतों को पूरा करने के लिए चुनते हैं।

लेकिन अगर ऐसा लगता है कि संदेश हैंडलर को सेट करने के लिए बहुत अधिक काम की आवश्यकता है (ऐसा लगता है) इसे एक अच्छे इंटरफ़ेस से संभाला जा सकता है? क्या मैं समाधान को पूरी तरह गलत समझ रहा हूं?

@PureKrome - इसे चर्चा के लिए लाने के लिए धन्यवाद। क्या आप कृपया विस्तार से बता सकते हैं कि "संदेश हैंडलर को सेटअप करने के लिए इतना काम करने की आवश्यकता है" से आपका क्या मतलब है?

नेटवर्क से टकराए बिना HttpClient को इकाई परीक्षण करने का एक तरीका है -

1. HttpMessageHandler . से प्राप्त एक नया हैंडलर वर्ग (जैसे FooHandler) बनाएं
2. अपनी आवश्यकताओं के अनुसार SendAsync विधि लागू करें - नेटवर्क को हिट न करें/अनुरोध-प्रतिक्रिया/आदि लॉग करें।
3. HttpClient के निर्माता में इस FooHandler का एक उदाहरण पास करें:
   वर हैंडलर = नया फूहैंडलर ();
   var क्लाइंट = नया HttpClient (हैंडलर);

तब आपका HttpClient ऑब्जेक्ट इनबिल्ट HttpClientHandler के बजाय आपके हैंडलर का उपयोग करेगा।

धन्यवाद,
सिड

नमस्ते @SidharthNabar - मेरे मुद्दे को पढ़ने के लिए धन्यवाद, मैं वास्तव में इसकी भी सराहना करता हूं।

एक नया हैंडलर क्लास बनाएं

तुमने सिर्फ मेरे सवाल का जवाब दिया :)

यह झूमने के लिए भी एक बड़ा नृत्य है, बस मेरा असली कोड पूछने के लिए कि _नेटवर्क को हिट न करें_।

मैंने एक HttpClient.Helpers repo और nuget पैकेज भी बनाया है .. बस परीक्षण को आसान बनाने के लिए! परिदृश्य की तरह हैप्पी पथ या नेटवर्क एंडपॉइंट द्वारा फेंका गया अपवाद ...

यही समस्या है -> क्या हम यह सब नहीं कर सकते हैं और ... इसके बजाय सिर्फ एक नकली विधि?

मैं कोड के माध्यम से कोशिश करूँगा और समझाऊंगा ..

लक्ष्य: इंटरवेब से कुछ डाउनलोड करें।

public async Foo GetSomethingFromTheInternetAsync()
{
    ....
    using (var httpClient = new HttpClient())
    {
        html = await httpClient.GetStringAsync("http://www.google.com.au");
    }
    ....
}

आइए दो उदाहरण देखें:

एक इंटरफ़ेस दिया गया है (यदि यह अस्तित्व में है):

public interface IHttpClient
{
    Task<string> GetStringAsync(string requestUri);    
}

मेरा कोड अब इस तरह दिख सकता है ...

public class SomeService(IHttpClient httpClient = null)
{
    public async Foo GetSomethingFromTheInternetAsync()
    {
        ....
        using (var httpClient = _httpClient ?? new HttpClient()) // <-- CHANGE dotnet/corefx#1
        {
            html = await httpClient.GetStringAsync("http://www.google.com.au");
        }
        ....
    } 
}

और परीक्षण वर्ग

public async Task GivenAValidEndPoint_GetSomethingFromTheInternetAsync_ReturnsSomeData()
{
    // Create the Mock : FakeItEasy > Moq.
    var httpClient = A.Fake<IHttpClient>();

    // Define what the mock returns.
    A.CallTo(()=>httpClient.GetStringAsync("http://www.google.com.au")).Returns("some html here");

    // Inject the mock.
    var service = new SomeService(httpClient);
    ...
}

वाह! किया हुआ।

ठीक है, अब वर्तमान तरीके से...

1. एक नया हैंडलर क्लास बनाएं - हाँ, एक क्लास!
2. हैंडलर को सेवा में इंजेक्ट करें

public class SomeService(IHttpClient httpClient = null)
{
    public async Foo GetSomethingFromTheInternetAsync()
    {
        ....
        using (var httpClient = _handler == null 
                                    ? new HttpClient()
                                    : new HttpClient(handler))
        {
            html = await httpClient.GetStringAsync("http://www.google.com.au");
        }
        ....
    } 
}

लेकिन दर्द अब यह है कि मुझे क्लास करनी पड़ रही है। तुमने अब मुझे चोट पहुंचाई है।

public class FakeHttpMessageHandler : HttpClientHandler
{
 ...
}

और यह कक्षा बहुत ही सरल रूप से शुरू होती है। जब तक मेरे पास एकाधिक GetAsync calls (इसलिए मुझे एकाधिक हैंडलर उदाहरण प्रदान करने की आवश्यकता है?) -या- एक ही सेवा में एकाधिक httpClients। साथ ही, क्या हम हैंडलर का Dispose करते हैं या इसका पुन: उपयोग करते हैं यदि हम तर्क के एक ही ब्लॉक में एकाधिक कॉल कर रहे हैं (जो एक सीटीआर विकल्प है)?

उदाहरण के लिए

public async Foo GetSomethingFromTheInternetAsync()
{
    string[] results;
    using (var httpClient = new HttpClient())
    {
        var task1 = httpClient.GetStringAsync("http://www.google.com.au");
        var task2 = httpClient.GetStringAsync("http://www.microsoft.com.au");

        results = Task.WhenAll(task1, task2).Result;
    }
    ....
}

इसे इसके साथ इतना आसान बनाया जा सकता है ..

var httpClient = A.Fake<IHttpClient>();
A.CallTo(() = >httpClient.GetStringAsync("http://www.google.com.au"))
    .Returns("gooz was here");
A.CallTo(() = >httpClient.GetStringAsync("http://www.microsoft.com.au"))
    .Returns("ms was here");

साफ साफ साफ :)

फिर - अगला बिट है: खोज योग्यता

जब मैंने पहली बार MS.Net.Http.HttpClient का उपयोग करना शुरू किया तो एपीआई बहुत स्पष्ट था: +1: ठीक है - स्ट्रिंग प्राप्त करें और इसे अतुल्यकालिक रूप से करें .. सरल ...

... लेकिन फिर मैंने परीक्षण किया .... और अब मुझे HttpClientHandlers के बारे में जानने का अनुमान है? उम क्यों? मुझे लगता है कि यह सब कवर के नीचे छुपाया जाना चाहिए और मुझे इस सभी कार्यान्वयन विवरण के बारे में चिंता करने की ज़रूरत नहीं है। यह तो ज्यादा है! आप कह रहे हैं कि मुझे बॉक्स के अंदर देखना शुरू करना चाहिए और कुछ प्लंबिंग सीखना चाहिए ... जो दर्द होता है: रोना:

यह सब आईएमओ की तुलना में इसे और अधिक जटिल बना रहा है।

मेरी मदद करें Microsoft - आप ही मेरी एकमात्र आशा हैं।

मुझे भी एचटीपी क्लाइंट का उपयोग करने वाली विभिन्न चीजों का परीक्षण करने का एक आसान और आसान तरीका देखना अच्छा लगेगा। :+1:

विस्तृत प्रतिक्रिया और कोड स्निपेट के लिए धन्यवाद - जो वास्तव में मदद करता है।

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

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

@ericstj - इस पर विचार?

धन्यवाद,
सिड।

@SidharthNabar आप/टीम इस वर्ग के लिए इंटरफ़ेस पेश करने में इतने संकोच क्यों कर रहे हैं? मैं उम्मीद कर रहा था कि एक डेवलपर के पूरे बिंदु को हैंडलर के बारे में _learn_ और फिर _create_ नकली हैंडलर कक्षाएं एक इंटरफ़ेस की आवश्यकता को उचित ठहराने (या कम से कम, हाइलाइट) करने के लिए पर्याप्त दर्द बिंदु है?

हाँ, मुझे नहीं लगता कि एक इंटरफेस एक बुरी चीज क्यों होगी। यह एचटीपी क्लाइंट का परीक्षण इतना आसान बना देगा।

फ्रेमवर्क में इंटरफेस से बचने के मुख्य कारणों में से एक यह है कि वे अच्छी तरह से संस्करण नहीं करते हैं। यदि आवश्यकता हो तो लोग हमेशा अपना स्वयं का बना सकते हैं और जब ढांचे के अगले संस्करण में एक नया सदस्य जोड़ने की आवश्यकता होती है तो यह टूटा नहीं जाएगा। @KrzysztofCwalina या @terrajobst इस डिज़ाइन दिशानिर्देश के अधिक इतिहास/विवरण को साझा करने में सक्षम हो सकते हैं। यह विशेष मुद्दा एक निकट धार्मिक बहस है: मैं इसमें भाग लेने के लिए बहुत व्यावहारिक हूं।

एचटीपी क्लाइंट के पास यूनिट टेस्टेबिलिटी के लिए बहुत सारे विकल्प हैं। यह सील नहीं है और इसके अधिकांश सदस्य आभासी हैं। इसमें एक बेस क्लास है जिसका उपयोग एब्स्ट्रैक्शन को सरल बनाने के साथ-साथ HttpMessageHandler में सावधानीपूर्वक डिज़ाइन किए गए एक्सटेंशन पॉइंट को @sharwell बताते हुए किया जा सकता है। IMO यह एक बहुत अच्छी तरह से डिज़ाइन किया गया API है, @HenrikFrystykNielsen के लिए धन्यवाद।

:+1: एक इंटरफ़ेस

:वेव: @ericstj कूदने के लिए धन्यवाद ढेर: +1:: केक:

फ्रेमवर्क में इंटरफेस से बचने के मुख्य कारणों में से एक यह है कि वे अच्छी तरह से संस्करण नहीं करते हैं।

हाँ - महान बिंदु।

यह विशेष मुद्दा एक निकट धार्मिक बहस है

हाँ ... उस पर अच्छी तरह से ध्यान दिया गया।

HttpClient के पास यूनिट टेस्टेबिलिटी के लिए बहुत सारे विकल्प हैं

ओह? मैं इस पर संघर्ष कर रहा हूं: ब्लश: इसलिए इस मुद्दे का कारण: ब्लश:

यह सील नहीं है और इसके अधिकांश सदस्य आभासी हैं।

सदस्य आभासी हैं? ओह ड्रेट्स, मैं पूरी तरह से चूक गया! यदि वे आभासी हैं, तो नकली ढांचे उन सदस्यों का मजाक उड़ा सकते हैं: +1: और हमें इंटरफ़ेस की आवश्यकता नहीं है!

आइए एक नजर डालते हैं HttpClient.cs पर ...

public Task<HttpResponseMessage> GetAsync(string requestUri) { .. }
public Task<HttpResponseMessage> GetAsync(Uri requestUri) { .. }

हम्म। वे वर्चुअल नहीं हैं ... फ़ाइल को खोजने दें ... एर .. कोई virtual कीवर्ड नहीं मिला। तो क्या आपका मतलब _other_ सदस्यों से _other related_ क्लासेस वर्चुअल हैं? यदि ऐसा है .. तो हम उस मुद्दे पर वापस आ गए हैं जो मैं उठा रहा हूं - हमें अब हुड के नीचे देखना होगा कि GetAsync क्या कर रहा है इसलिए हम जानते हैं कि क्या बनाना है/वायरअप/आदि...

मुझे लगता है कि मैं वास्तव में कुछ बुनियादी समझ नहीं रहा हूँ, यहाँ ¯(°_°)/¯ ?

संपादित करें: शायद वे विधियां आभासी हो सकती हैं? मैं पीआर कर सकता हूँ!

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

आह! गोचा: ब्लश: तो वे सभी विधियां SendAsync .. को कॉल करना समाप्त कर देती हैं .. जो सभी भारी भारोत्तोलन करता है। तो इसका अभी भी मतलब है कि हमारे पास यहां एक खोज योग्यता समस्या है .. लेकिन इसे एक तरफ रख दें (यह माना जाता है)।

हम SendAsync का मज़ाक कैसे उड़ाएंगे यह मूल नमूना देंगे...
Install-Package Microsoft.Net.Http
Install-Package xUnit

public class SomeService
{
    public async Task<string> GetSomeData(string url)
    {
        string result;
        using (var httpClient = new HttpClient())
        {
            result = await httpClient.GetStringAsync(url);
        }

        return result;
    }
}

public class Facts
{
    [Fact]
    public async Task GivenAValidUrl_GetSomeData_ReturnsSomeData()
    {
        // Arrange.
        var service = new SomeService();

        // Act.
        var result = await service.GetSomeData("http://www.google.com");

        // Assert.
        Assert.True(result.Length > 0);
    }
}

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

मैं पूरी तरह से .NET Framework के साथ सोचने के इस तरीके को पूरी तरह से समझ सकता हूं।

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

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

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

मेरे दो सेंट।

@MrJul : +1:
वर्जनिंग कोई समस्या नहीं होनी चाहिए। इसलिए संस्करण संख्याएँ मौजूद हैं :)

वर्जनिंग अभी भी बहुत ज्यादा एक मुद्दा है। किसी सदस्य को इंटरफ़ेस में जोड़ना एक महत्वपूर्ण परिवर्तन है। इस तरह की कोर लाइब्रेरी के लिए जो डेस्कटॉप में इनबॉक्स हैं, हम भविष्य के संस्करणों में सुविधाओं को डेस्कटॉप पर वापस लाना चाहते हैं। अगर हम फोर्क करते हैं तो इसका मतलब है कि लोग पोर्टेबल कोड नहीं लिख सकते हैं जो दोनों जगहों पर चलेगा। परिवर्तनों को तोड़ने के बारे में अधिक जानकारी के लिए यहां देखें: https://github.com/dotnet/corefx/wiki/Breking-Changes।

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

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

यदि आपके पास एक विशिष्ट संगत परिवर्तन है, तो आप एचटीपी क्लाइंट को सुझाव देना चाहेंगे जो यूनिट टेस्टेबिलिटी में सुधार करता है, कृपया इसे प्रस्तावित करें और @SidharthNabar और उनकी टीम इस पर विचार कर सकती है।

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

@KrzysztofCwalina आप, सर, सिर पर कील ठोकें! सही सारांश!

मुझे लगता है कि मैं इस तर्क का कम लोकप्रिय पक्ष लेने जा रहा हूं क्योंकि मुझे व्यक्तिगत रूप से नहीं लगता कि एक इंटरफ़ेस आवश्यक है। जैसा कि पहले ही बताया जा चुका है, HttpClient पहले से ही अमूर्त है। व्यवहार वास्तव में HttpMessageHandler से आता है। हां, Moq या FakeItEasy जैसे ढांचे के आदी हो चुके दृष्टिकोणों का उपयोग करके यह नकली/नकली नहीं है, लेकिन इसकी आवश्यकता नहीं है; चीजें करने का यह _only_ तरीका नहीं है। हालांकि एपीआई अभी भी डिजाइन द्वारा पूरी तरह से परीक्षण योग्य है।

तो चलिए "मुझे अपना खुद HttpMessageHandler बनाने की आवश्यकता है?" को संबोधित करते हैं। नही बिल्कुल नही। हम सभी ने अपनी मॉकिंग लाइब्रेरी नहीं लिखी। @PureKrome पहले ही अपनी HttpClient.Helpers लाइब्रेरी दिखा चुका है। व्यक्तिगत रूप से मैंने इसका इस्तेमाल नहीं किया है, लेकिन मैं इसे देख लूंगा। मैं @richardszalay की MockHttp लाइब्रेरी का उपयोग कर रहा हूं जो मुझे शानदार लगती है। यदि आपने कभी AngularJS के $httpBackend के साथ काम किया है, तो MockHttp बिल्कुल वैसा ही तरीका अपना रहा है।

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

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

व्यक्तिगत रूप से, एक इंटरफ़ेस या वर्चुअल तरीके मेरे लिए बहुत मायने नहीं रखते। लेकिन चलो, perfectly testable थोड़ा बहुत है :)

@luisrudge ठीक है क्या आप एक ऐसा परिदृश्य दे सकते हैं जिसे परीक्षण की संदेश हैंडलर शैली का उपयोग करके परीक्षण नहीं किया जा सकता है कि MockHttp जैसी कोई चीज़ सक्षम है? शायद इससे मामला बनाने में मदद मिलेगी।

मुझे कुछ भी ऐसा नहीं मिला है जिसे मैं अभी तक संहिताबद्ध नहीं कर सका, लेकिन शायद मुझे कुछ और गूढ़ परिदृश्य याद आ रहे हैं जिन्हें कवर नहीं किया जा सकता है। फिर भी, उस पुस्तकालय की एक गायब विशेषता हो सकती है जिसमें कोई योगदान दे सकता है।

अभी के लिए मैं इस राय को बनाए रखता हूं कि यह एक निर्भरता के रूप में "पूरी तरह से परीक्षण योग्य" है, बस एक तरह से नहीं। NET देवों का उपयोग किया जाता है।

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

कोई तर्क दे सकता है कि एस्पनेट एमवीसी 5 पूरी तरह से परीक्षण योग्य है, आपको नियंत्रक की हर चीज की नकल करने के लिए केवल 50LOC लिखना होगा। आईएमएचओ, एचटीपी क्लाइंट के साथ भी यही मामला है। यह परीक्षण योग्य है? हां। परीक्षण करना आसान है? नहीं।

@luisrudge हां, मैं सहमत हूं, यह व्यक्तिपरक है और मैं इंटरफ़ेस/वर्चुअल की इच्छा को पूरी तरह से समझता हूं। मैं बस यह सुनिश्चित करने की कोशिश कर रहा हूं कि जो कोई भी साथ आता है और इस धागे को पढ़ता है उसे कम से कम इस तथ्य पर कुछ शिक्षा मिल जाएगी कि यह एपीआई _can be_ एक कोड बेस में एक बहुत ही परीक्षण योग्य तरीके से HttpClient के आसपास अपने स्वयं के सार को पेश किए बिना लीवरेज किया गया है

अगर आपको बाहरी lib का उपयोग करना है जो आपको ऐसा करने में मदद करता है, तो यह पूरी तरह से परीक्षण योग्य नहीं है

ठीक है, हम सभी एक पुस्तकालय या किसी अन्य का उपयोग पहले से ही मजाक/नकली करने के लिए कर रहे हैं ^* और, यह सच है, हम एपीआई की इस शैली का परीक्षण करने के लिए सिर्फ _that_ एक का उपयोग नहीं कर सकते हैं, लेकिन मुझे नहीं लगता कि इसका मतलब इससे कम परीक्षण योग्य है एक इंटरफ़ेस आधारित दृष्टिकोण सिर्फ इसलिए कि मुझे एक और पुस्तकालय लाना है।

_ ^* कम से कम मुझे उम्मीद नहीं है!_

मेरे ओपी से @ drub0y मैंने कहा है कि पुस्तकालय परीक्षण योग्य है - लेकिन यह केवल एक वास्तविक दर्द है (जो मैं जुनून से विश्वास करता हूं) की तुलना में यह क्या हो सकता है। IMO @luisrudge ने इसे पूरी तरह से लिखा है:

कोई तर्क दे सकता है कि एस्पनेट एमवीसी 5 पूरी तरह से परीक्षण योग्य है, आपको नियंत्रक की हर चीज की नकल करने के लिए केवल 50LOC लिखना होगा

यह रेपो _बड़ी संख्या में डेवलपर्स का एक प्रमुख हिस्सा है। तो डिफ़ॉल्ट (और समझने योग्य) रणनीति इस रेपो के साथ _very_ सतर्क रहना है। ज़रूर - मैं पूरी तरह से समझ गया।

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

तो वर्तमान एपीआई के साथ - क्या इसका परीक्षण किया जा सकता है? हां। क्या यह डार्क मैटर डेवलपर टेस्ट पास करता है? मैं व्यक्तिगत रूप से ऐसा नहीं सोचता।

लिटमस टेस्ट आईएमओ यह है: क्या एक नियमित जो पिकअप आम/लोकप्रिय परीक्षण ढांचे + मॉकिंग फ्रेमवर्क में से एक है और इस एपीआई में किसी भी मुख्य तरीके का मजाक उड़ा सकता है? अभी - नहीं। तो फिर डेवलपर को अपने काम को रोकना होगा और इस लाइब्रेरी के _इम्प्लीमेंटेशन_ के बारे में सीखना शुरू करना होगा।

जैसा कि पहले ही बताया जा चुका है, HttpClient पहले से ही अमूर्त है। व्यवहार वास्तव में HttpMessageHandler से आता है।

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

ऐसा लगता है ... उलझा हुआ।

हम इतने सारे लोगों के लिए जीवन को आसान बनाने और रक्षात्मक स्थिति में वापस आने की स्थिति में हैं: "यह किया जा सकता है - लेकिन .. अक्सर पूछे जाने वाले प्रश्न/कोड पढ़ें"।

इस मुद्दे पर पहुंचने के लिए एक और कोण है: यादृच्छिक गैर-एमएस देवों को 2 उदाहरण दें ... जो नागरिक डेवलपर्स जो जानते हैं कि xUnit और Moq/FakeItEasy/InsertTheHipMockingFrameworkThisYear का उपयोग कैसे करें।

• पहला एपीआई जो इंटरफ़ेस/वर्चुअल/जो कुछ भी उपयोग करता है .. लेकिन विधि का मज़ाक उड़ाया जा सकता है।
• दूसरा एपीआई जो सिर्फ एक सार्वजनिक तरीका है और _integration point_ का मजाक उड़ाने के लिए .. उन्हें कोड पढ़ना होगा।

यह उस पर निर्भर करता है, आईएमओ।

देखें कि कौन सा डेवलपर उस समस्या को हल कर सकता है _और_ खुश रहें।

यदि एपीआई नकली नहीं है, तो हमें इसे ठीक करना चाहिए।

अभी यह आईएमओ नहीं है - लेकिन इसे सफलतापूर्वक प्राप्त करने के तरीके हैं (फिर से, यह माना जाता है - मैं इसे स्वीकार करूंगा)

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

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

@luisrudge अगर आपको बाहरी lib का उपयोग करना है जो आपको ऐसा करने में मदद करता है, तो यह पूरी तरह से परीक्षण योग्य नहीं है
@ drub0y ठीक है, हम सभी एक पुस्तकालय या किसी अन्य का उपयोग पहले से ही मजाक/नकली करने के लिए कर रहे हैं

(मुझे आशा है कि मैं समझ गया था कि अंतिम उद्धरण/पैराग्राफ ..) नहीं ... शांत। @luisrudge क्या कह रहा था: "हमारे पास परीक्षण के लिए एक उपकरण है। मजाक के लिए दूसरा उपकरण। अब तक, वे एक सामान्य/समग्र उपकरण किसी भी चीज़ से बंधे नहीं हैं। लेकिन .. अब आप चाहते हैं कि मैं एक तीसरा टूल डाउनलोड करूं जो _specific_ है। हमारे कोड में एक _specific_ API/सेवा का मज़ाक उड़ाने के लिए क्योंकि हम जिस विशिष्ट API/सेवा का उपयोग कर रहे हैं, उसे अच्छी तरह से परीक्षण करने के लिए डिज़ाइन नहीं किया गया था?"। यह थोड़ा समृद्ध है :(

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

पूरी तरह से सहमत! तो, क्या आप हमें यह दिखाने के लिए उपरोक्त नमूना कोड को दोबारा कर सकते हैं कि यह कितना आसान होना चाहिए/हो सकता है? बिल्ली की खाल उतारने के कई तरीके हैं ... तो एक सरल और आसान तरीका क्या है? हमें कोड दिखाएं।

मैं शुरू करूंगा। इंटरफ़ेस का उपयोग करने के लिए @KrzysztofCwalina से क्षमा याचना, लेकिन यह सिर्फ मेरे लिटमस टेस्ट को किकस्टार्ट करने के लिए है।

public interface IHttpClient
{
    Task<string> GetStringAsync(string url);
}

public class SomeService
{
    private IHttpClient _httpClient;

    // Injected.
    public SomeService(IHttpClient httpClient) { .. }

    public async Task<string> GetSomeData(string url)
    {
        string result;
        using (var httpClient = _httpClient ?? new HttpClient())
        {
            result = await httpClient.GetStringAsync(url);
        }

        return result;
    }    
}

ऐसा लगता है कि सभी @PureKrome की जरूरत एक दस्तावेज अपडेट है जो बताती है कि परीक्षण के दौरान एपीआई के व्यवहार को अनुकूलित करने के लिए कौन से तरीकों को नकल/ओवरराइड करना है।

@ शारवेल बिल्कुल ऐसा नहीं है। जब मैं सामान का परीक्षण करता हूं, तो मैं संपूर्ण httpclient कोड नहीं चलाना चाहता:
SendAsync विधि देखें।
यह पागल है। आप जो सुझाव दे रहे हैं वह यह है कि प्रत्येक डेवलपर को कक्षा से आंतरिक पता होना चाहिए, जीथब खोलें, कोड देखें और उस तरह की चीजें इसका परीक्षण करने में सक्षम हों। मैं चाहता हूं कि वह डेवलपर GetStringAsync का मजाक उड़ाए और बकवास करे।

@luisrudge वास्तव में मेरा सुझाव इस पुस्तकालय के लिए पूरी तरह से मजाक करने से बचना होगा। चूंकि आपके पास पहले से ही एक साफ अमूर्त परत है जिसमें एक डिकूप्ड, प्रतिस्थापन योग्य कार्यान्वयन है, अतिरिक्त मॉकिंग अनावश्यक है। इस पुस्तकालय के लिए उपहास में निम्नलिखित अतिरिक्त कमियां हैं:

1. परीक्षण बनाने वाले डेवलपर्स पर बोझ बढ़ गया (मॉक बनाए रखना), जो बदले में विकास लागत को बढ़ाता है
2. इस बात की संभावना बढ़ जाती है कि आपके परीक्षण कुछ समस्याग्रस्त व्यवहारों का पता लगाने में विफल हो जाएंगे, जैसे कि किसी संदेश से जुड़ी सामग्री स्ट्रीम का पुन: उपयोग करना (सामग्री स्ट्रीम पर Dispose पर कॉल के परिणामस्वरूप संदेश भेजना, लेकिन अधिकांश मॉक इसे अनदेखा कर देंगे)
3. एक विशेष अमूर्त परत के लिए आवेदन के अनावश्यक रूप से सख्त युग्मन, जो HttpClient के विकल्पों के मूल्यांकन से जुड़ी विकास लागत को बढ़ाता है

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

चूंकि आपके पास पहले से ही एक साफ अमूर्त परत है जिसमें एक डिकूप्ड, प्रतिस्थापन योग्य कार्यान्वयन है, अतिरिक्त मॉकिंग अनावश्यक है

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

मैं पहले @luisrudge की टिप्पणी से सहमत हूं। _तकनीकी रूप से_ MVC5 परीक्षण योग्य था, लेकिन मेरे भगवान यह गधे में दर्द था और बालों को खींचने का एक बहुत बड़ा स्रोत था।

@sharwell क्या आप कह रहे हैं कि IHttpClient का मज़ाक उड़ाना एक बोझ है और एक नकली संदेश हैंडलर को लागू करना (जैसे यह नहीं है? मैं इससे सहमत नहीं हो सकता, क्षमा करें।

@luisrudge परीक्षण के सरल मामलों के लिए GetStringAsync , हैंडलर का मजाक उड़ाना इतना कठिन नहीं है। आउट-ऑफ-द-बॉक्स Moq + HttpClient का उपयोग करना, आपको बस यह चाहिए:

Uri requestUri = new Uri("http://google.com");
string expectedResponse = "Response text";

Mock<HttpClientHandler> mockHandler = new Mock<HttpClientHandler>();
mockHandler.Protected()
    .Setup<Task<HttpResponseMessage>>("SendAsync", ItExpr.Is<HttpRequestMessage>(message => message.RequestUri == requestUri), ItExpr.IsAny<CancellationToken>())
    .Returns(Task.FromResult(new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent(expectedResponse) }));
HttpClient httpClient = new HttpClient(mockHandler.Object);
string result = await httpClient.GetStringAsync(requestUri).ConfigureAwait(false);
Assert.AreEqual(expectedResponse, result);

यदि यह बहुत अधिक है, तो आप एक सहायक वर्ग को परिभाषित कर सकते हैं:

internal static class MockHttpClientHandlerExtensions
{
    public static void SetupGetStringAsync(this Mock<HttpClientHandler> mockHandler, Uri requestUri, string response)
    {
        mockHandler.Protected()
            .Setup<Task<HttpResponseMessage>>("SendAsync", ItExpr.Is<HttpRequestMessage>(message => message.RequestUri == requestUri), ItExpr.IsAny<CancellationToken>())
            .Returns(Task.FromResult(new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent(response) }));
    }
}

आपको केवल सहायक वर्ग का उपयोग करना चाहिए:

Uri requestUri = new Uri("http://google.com");
string expectedResponse = "Response text";

Mock<HttpClientHandler> mockHandler = new Mock<HttpClientHandler>();
mockHandler.SetupGetStringAsync(requestUri, expectedResponse);
HttpClient httpClient = new HttpClient(mockHandler.Object);
string result = await httpClient.GetStringAsync(requestUri).ConfigureAwait(false);
Assert.AreEqual(expectedResponse, result);

तो दो संस्करणों की तुलना करने के लिए:
_अस्वीकरण_: यह परीक्षण नहीं किया गया है, ब्राउज़र कोड। इसके अलावा, मैंने उम्र में Moq का उपयोग नहीं किया है।

वर्तमान

public class SomeService(HttpClientHandler httpClientHandler= null)
{
    public async Foo GetSomethingFromTheInternetAsync()
    {
        ....
        using (var httpClient = _handler == null
                                  ? new HttpClient
                                  : new HttpClient(handler))
        {
            html = await httpClient.GetStringAsync("http://www.google.com.au");
        }
        ....
    } 
}

// Unit test...
// Arrange.
Uri requestUri = new Uri("http://google.com");
string expectedResponse = "Response text";
var responseMessage = new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent(expectedResponse) };
Mock<HttpClientHandler> mockHandler = new Mock<HttpClientHandler>();
mockHandler.Protected()
    .Setup<Task<HttpResponseMessage>>("SendAsync", ItExpr.Is<HttpRequestMessage>(message => message.RequestUri == requestUri), ItExpr.IsAny<CancellationToken>())
    .ReturnsAsync(responseMessage);
HttpClient httpClient = new HttpClient(mockHandler.Object);
var someService = new SomeService(mockHandler.Object); // Injected...

// Act.
string result = await someService.GetSomethingFromTheInternetAsync();

// Assert.
Assert.AreEqual(expectedResponse, result);
httpClient.Verify(x => x.GetSomethingFromTheInternetAsync(), Times.Once);

बनाम एपीआई विधि को सीधे नकल करने का एक तरीका प्रदान करना।

एक और तरीका

public class SomeService(IHttpClient httpClient = null)
{
    public async Foo GetSomethingFromTheInternetAsync()
    {
        ....
        using (var httpClient = _httpClient ?? new HttpClient())
        {
            html = await httpClient.GetStringAsync("http://www.google.com.au");
        }
        ....
    } 
}

// Unit tests...
// Arrange.
var response = new Foo();
var httpClient = new Mock<IHttpClient>();
httpClient.Setup(x => x.GetStringAsync(It.IsAny<string>))
    .ReturnsAsync(response);
var service = new SomeService(httpClient.Object); // Injected.

// Act.
var result = await service.GetSomethingFromTheInternetAsync();

// Assert.
Assert.Equals("something", foo.Something);
httpClient.Verify(x => x.GetStringAsync(It.IsAny<string>()), Times.Once);

इसे कम करके, यह मुख्य रूप से इस पर आता है ( SomeService में मामूली अंतर को छोड़कर) ...

var responseMessage = new HttpResponseMessage(HttpStatusCode.OK) { Content = new StringContent(expectedResponse) };
Mock<HttpClientHandler> mockHandler = new Mock<HttpClientHandler>();
mockHandler.Protected()
    .Setup<Task<HttpResponseMessage>>("SendAsync", ItExpr.Is<HttpRequestMessage>(message => message.RequestUri == requestUri), ItExpr.IsAny<CancellationToken>())
    .ReturnsAsync(responseMessage);
HttpClient httpClient = new HttpClient(mockHandler.Object);

यह बनाम ...

var httpClient = new Mock<IHttpClient>();
httpClient.Setup(x => x.GetStringAsync(It.IsAny<string>))
    .ReturnsAsync(response);

क्या कोड _मोटे तौर पर दोनों के लिए सही दिखता है? (दोनों की तुलना करने से पहले दोनों को काफी सटीक होना चाहिए)।

@sharwell तो मुझे अपने परीक्षण चलाने के लिए सभी HttpClient.cs कोड के माध्यम से अपना कोड चलाना होगा? यह कम एचटीपी क्लाइंट के साथ कैसे जुड़ा हुआ है?

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

अपनी लाइब्रेरी के लिए कूडो से @PureKrome , लेकिन यह बेहतर होगा यदि यह आवश्यक न हो :)

मैंने अभी सभी टिप्पणियां पढ़ी हैं और बहुत कुछ सीखा है, लेकिन मेरा एक प्रश्न है: आपको अपने परीक्षणों में एचटीपी क्लाइंट का नकल करने की आवश्यकता क्यों है?

अधिकांश सामान्य परिदृश्यों में HttpClient द्वारा प्रदान की जाने वाली कार्यक्षमता पहले से ही किसी वर्ग जैसे HtmlDownloader.DownloadFile() में लपेटी जाएगी। प्लंबिंग के बजाय इस वर्ग का मजाक क्यों न उड़ाएं?

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

मैं यह नहीं कह रहा हूं कि इसकी टेस्टेबिलिटी में सुधार नहीं किया जा सकता है, न ही इसका मतलब यह है कि यह नहीं होना चाहिए। मैं बस कुछ नई चीजें सीखने के लिए समझना चाहता हूं।

@tucaz आइए कल्पना करें कि मेरे पास एक वेबसाइट है जो आपके बारे में कुछ जानकारी लौटाती है। आपकी उम्र, नाम, जन्मदिन इत्यादि। आपके पास कुछ कंपनियों में स्टॉक भी होता है।

आपने कहा है कि आपके पास एएए स्टॉक की 100 इकाइयां और बीबीबी स्टॉक की 200 इकाइयां हैं? इसलिए, जब हम आपके खाते के विवरण प्रदर्शित करते हैं तो हम प्रदर्शित करते हैं कि आपके स्टॉक की कीमत कितनी है।

ऐसा करने के लिए, हमें _another_ सिस्टम से मौजूदा स्टॉक की कीमतों को हथियाने की जरूरत है। तो ऐसा करने के लिए, हमें स्टॉक को एक सेवा के साथ पुनः प्राप्त करने की आवश्यकता है, है ना? इस करने दो...

_अस्वीकरण: ब्राउज़र कोड..._

public class StockService : IStockService
{
    private readonly IHttpClient _httpClient;

    public StockService(IHttpClient httpClient)
    {
        _httpClient = httpClient; // Optional.
    }

    public async Task<IEnumerable<StockResults>> GetStocksAsync(IEnumerable<string> stockCodes)
    {
        var queryString = ConvertStockCodeListIntoQuerystring();
        string jsonResult;
        using (var httpClient = _httpClient ?? new HttpClient())
        {
            jsonResult = await httpClient.GetStringAsync("http:\\www.stocksOnline.com\stockResults?" + queryString);
        }

        return JsonConvert.DeserializeObject<StockResult>(jsonResult);
    }
}

ठीक है, तो यहां हमारे पास एक सरल सेवा है जो कहती है: "_गो मुझे स्टॉक एएए और बीबीबी_ के लिए स्टॉक की कीमतें प्राप्त करें";

तो, मुझे इसका परीक्षण करने की ज़रूरत है:

• कुछ वैध स्टॉक नामों को देखते हुए
• कुछ अमान्य/गैर-मौजूद स्टॉक नामों को देखते हुए
• httpClient एक अपवाद फेंकता है (प्रतिक्रिया की प्रतीक्षा करते समय इंटरनेट उड़ गया)

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

बेशक - मैं अपने सामान्य यूनिट परीक्षणों के दौरान 100% वास्तव में वास्तविक वेब सेवा को हिट नहीं करना चाहता हूं। नकली इंजेक्शन लगाकर, मैं इसका इस्तेमाल कर सकता हूं। अन्यथा मैं एक नया उदाहरण बना सकता हूं और उसका उपयोग कर सकता हूं।

तो मैं यह स्थापित करने की कोशिश कर रहा हूं कि मेरा सुझाव एक नरकवा बहुत आसान है (पढ़ने/बनाए रखने/आदि) कि वर्तमान स्थिति।

अधिकांश सामान्य परिदृश्यों में HttpClient द्वारा प्रदान की जाने वाली कार्यक्षमता पहले से ही कुछ वर्ग जैसे HtmlDownloader.DownloadFile() में लपेटी जाएगी।

हमें एचटीपी क्लाइंट को क्यों लपेटना चाहिए? यह _पहले से ही सभी http :sparkles: नीचे एक एब्स्ट्रैक्शन है। यह एक महान पुस्तकालय है! मैं व्यक्तिगत रूप से नहीं देखता कि इससे क्या हासिल होगा?

@PureKrome आपके उपयोग का उदाहरण ठीक वही है जो एक रैपिंग क्लास में कार्यक्षमता को लपेटकर मेरा मतलब है।

मुझे यकीन नहीं है कि मैं समझ सकता हूं कि आप क्या परीक्षण करने की कोशिश कर रहे हैं, लेकिन मेरे लिए ऐसा लगता है कि आप अंतर्निहित webservice का परीक्षण कर रहे हैं, जब आपको वास्तव में जोर देने की ज़रूरत है कि जो कोई भी उपभोग कर रहा है वह GetStockAsync से वापस आने वाली चीज़ों को संभालने में सक्षम होगा

कृपया निम्नलिखित पर विचार करें:

private IStockService stockService;

[Setup]
public void Setup()
{
    stockService = A.Fake<IStockService>();

    A.CallTo(() => stockService.GetStocksAsync(new [] { "Ticker1" }))
        .Returns(new StockResults[] { new StockResults { Price = 100m, Ticker = "Ticker1", Status = "OK" }});
    A.CallTo(() => stockService.GetStocksAsync(new [] { "Ticker2" }))
        .Returns(new StockResults[] { new StockResults { Price = 0m, Ticker = "Ticker2", Status = "NotFound" }});
    A.CallTo(() => stockService.GetStocksAsync(new [] { "Ticker3" }))
        .Throws(() => new InvalidOperationException("Some weird message"));
}

[Test]
public async void Get_Total_Stock_Quotes()
{
    var stockService = A.Fake<IStockService>();

    var total = await stockService.GetStockAsync(new [] { "Ticker1" });

    Assert.IsNotNull(total);
    Assert.IsGreaterThan(0, total.Sum(x => x.Price);
}

[Test]
public async void Hints_When_Ticker_Not_Found()
{
    var stockService = A.Fake<IStockService>();

    var total = await stockService.GetStockAsync(new [] { "Ticker2" });

    Assert.IsNotNull(total);
    Assert.AnyIs(x => x.Status == "NotFound");
}

[Test]
public async void Throws_InvalidOperationException_When_Error()
{
    var stockService = A.Fake<IStockService>();

    Assert.Throws(() => await stockService.GetStockAsync(new [] { "Ticker3" }), typeof(InvalidOperationException));
}

मैं प्रस्ताव कर रहा हूं कि आप अपने एब्स्ट्रैक्शन को एक स्तर ऊपर बढ़ाएं और वास्तविक व्यावसायिक तर्क से निपटें क्योंकि ऐसा कुछ भी नहीं है जिसे GetStockAsync पद्धति के व्यवहार के संबंध में परीक्षण करने की आवश्यकता हो।

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

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

@tucaz क्या आपने अभी यह परीक्षण नहीं किया है कि आपके नकली रिटर्न जो आपने कॉन्फ़िगर किए हैं, प्रभावी रूप से मॉकिंग लाइब्रेरी का परीक्षण कर रहे हैं? @PureKrome ठोस StockService कार्यान्वयन का परीक्षण करना चाहता है।

$#$2 StockService का ठीक से परीक्षण करने में सक्षम होने के लिए अमूर्तता के नए शुरू किए गए स्तर को HttpClient कॉल लपेटना चाहिए। संभावना है कि रैपर बस प्रत्येक कॉल को HttpClient पर सौंप देगा, और एप्लिकेशन में अनावश्यक जटिलता जोड़ देगा।

गैर-नकली प्रकारों को छिपाने के लिए आप हमेशा अमूर्तता की एक नई परत जोड़ सकते हैं। इस सूत्र में जिस चीज की आलोचना की गई है, वह यह है कि HttpClient का मजाक उड़ाना संभव है, लेकिन संभवत: अन्य पुस्तकालयों के साथ जो किया जाता है, उसके अनुरूप होना चाहिए।

@MrJul आप सही कह रहे हैं। इसलिए मैंने कहा कि उसके उदाहरण से जो परीक्षण किया गया है वह स्वयं webservice कार्यान्वयन है और मैंने क्यों प्रस्तावित किया (बिना कोड उदाहरणों के। मेरा बुरा) कि वह IStockService का मजाक उड़ाता है ताकि वह दावा कर सके कि इसका उपभोग करने वाला कोड सक्षम है जो कुछ भी GetStockAsync लौटाता है उसे संभाल लें।

मुझे लगता है कि पहले स्थान पर इसका परीक्षण किया जाना चाहिए। नकली ढांचा नहीं (जैसे मैंने किया) या webservice कार्यान्वयन (जैसे @PureKrome करना चाहता है)।

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

@tucaz नहीं । आपका परीक्षण गलत है। आप मॉकिंग लाइब्रेरी का परीक्षण कर रहे हैं। @PureKrome के उदाहरण का उपयोग करते हुए, कोई तीन चीजों का परीक्षण करना चाहेगा:

• अगर http अनुरोध सही METHOD . का उपयोग कर रहा है
• अगर http अनुरोध में URL . का अधिकार है
• यदि प्रतिक्रिया निकाय को सफलतापूर्वक एक json deserializer के साथ deserialized किया जा सकता है

यदि आप अपने नियंत्रक (उदाहरण के लिए) में सिर्फ IStockService का मजाक उड़ाते हैं, तो आप ऊपर वर्णित तीन चीजों में से किसी का भी परीक्षण नहीं कर रहे हैं।

@luisrudge आपकी सभी बातों से सहमत हैं। लेकिन ... क्या इन सभी चीजों का परीक्षण करने का मूल्य है जो आप इसके लायक हैं? मेरा मतलब है, अगर मैं उन सभी बुनियादी चीजों का परीक्षण करने के लिए प्रतिबद्ध हूं जो कई ढांचे (json.net, httpclient, आदि) द्वारा कवर किए गए हैं, तो मुझे लगता है कि मैं इसे आज जिस तरह से कर सकता हूं उसे संभाल सकता हूं।

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

मेरी राय यह है कि आप जिन परीक्षणों का प्रस्ताव कर रहे हैं उनका न्यूनतम निवल मूल्य है और आपको इस पर तभी काम करना चाहिए जब आपके पास अपने आवेदन का अन्य 99% शामिल हो। लेकिन अंत में यह सब व्यक्तिगत पसंद का मामला है और यह एक व्यक्तिपरक विषय है जहां अलग-अलग लोग अलग-अलग मूल्य देखते हैं। और यह, ज़ाहिर है, इसका मतलब यह नहीं है कि HttpClient अधिक परीक्षण योग्य नहीं होना चाहिए।

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

जब मैंने पहली बार बात की थी तो मेरे दिमाग में जो उद्देश्य था, वह @PureKrome को अपने प्रयासों पर ध्यान केंद्रित न करने में मदद करना था, जो मुझे लगता है कि यह एक कम मूल्य वाला कार्य है। लेकिन फिर, यह सब किसी बिंदु पर व्यक्तिगत राय पर आता है।

यह सुनिश्चित करने के लिए कि आपने सही url मारा है, आपके लिए निम्न शुद्ध मूल्य है? यह सुनिश्चित करने के बारे में क्या है कि आप किसी पोस्ट के बजाय संसाधन को संपादित करने के लिए एक पुट अनुरोध करते हैं? मेरे अन्य 99% ऐप को कवर किया जा सकता है, अगर यह कॉल विफल हो जाती है, तो कुछ भी काम नहीं करेगा।

बहुत, मुझे सच में लगता है कि HttpClient::GetStringAsync के बारे में बात करना पहली जगह में HttpClient का मजाक उड़ाने में सक्षम होने का मामला बनाने का एक खराब तरीका है। यदि आप किसी भी HttpClient::Get[String|Stream|ByteArray]Async विधियों का उपयोग कर रहे हैं जो आप पहले ही खो चुके हैं क्योंकि आप कोई उचित त्रुटि प्रबंधन नहीं कर सकते हैं क्योंकि सब कुछ एक HttpRequestException के पीछे छिपा हुआ है जिसे फेंक दिया जाएगा और वह नहीं करता है 'HTTP स्थिति कोड जैसे महत्वपूर्ण विवरणों को भी उजागर न करें। तो इसका मतलब है कि आपने HttpClient के शीर्ष पर जो भी अमूर्तता बनाई है, उसमें विशिष्ट HTTP त्रुटियों को डोमेन विशिष्ट अपवादों पर प्रतिक्रिया करने और अनुवाद करने की कोई क्षमता नहीं होगी और अब आप अपने आप को एक लीकी एब्स्ट्रैक्शन प्राप्त कर चुके हैं ... और एक जो आपकी डोमेन सेवा के कॉलर्स को भयानक अपवाद जानकारी कम नहीं देता है।

मुझे लगता है कि इसे इंगित करना महत्वपूर्ण है क्योंकि, ज्यादातर मामलों में, इसका मतलब है कि यदि आप एक नकली दृष्टिकोण का उपयोग कर रहे थे तो आप HttpClient विधियों का मज़ाक उड़ा रहे होंगे जो $#$6 HttpResponseMessage लौटाते हैं जो आपको पहले ही प्राप्त कर लेता है HttpMessageHandler::SendAsync का नकली/नकली करने के लिए उतनी ही मात्रा में काम करना पड़ता है। वास्तव में, यह अधिक है! आपको संभावित रूप से HttpMessageHandler स्तर पर केवल SendAsync का मज़ाक उड़ाने के बजाय HttpClient HttpMessageHandler पर कई तरीकों (जैसे [Get|Put|Delete|Send]Async ) का मज़ाक उड़ाना होगा।

@luisrudge ने JSON को deserializing का भी उल्लेख किया है, इसलिए अब हम HttpContent के साथ काम करने के बारे में बात कर रहे हैं जिसका अर्थ है कि आप उन तरीकों में से एक के साथ काम कर रहे हैं जो निश्चित रूप से HttpResponseMessage लौटाते हैं। जब तक आप यह नहीं कह रहे हैं कि आप संपूर्ण मीडिया फ़ॉर्मेटर आर्किटेक्चर को दरकिनार कर रहे हैं और स्ट्रिंग को GetStringAsync से ऑब्जेक्ट इंस्टेंस में मैन्युअल रूप से JsonSerializer::Deserialize या जो भी हो। अगर ऐसा है तो मुझे नहीं लगता कि हम वास्तव में _testing_ एपीआई के बारे में और बातचीत कर सकते हैं क्योंकि वह सिर्फ एपीआई _खुद_ का पूरी तरह से गलत उपयोग करेगा। :निराश:

@luisrudge यह वास्तव में महत्वपूर्ण है, लेकिन यह सुनिश्चित करने के लिए कि यह सही है, आपको HttpClient को छूने की आवश्यकता नहीं है। बस यह सुनिश्चित करें कि जिस स्रोत से आपने URL पढ़ा है, वह सही ढंग से चीजें लौटा रहा है और आप जाने के लिए अच्छे हैं। फिर, इसमें HttpClient के साथ एकीकरण परीक्षण करने की आवश्यकता नहीं है।

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

@tucaz सहमत हैं। फिर भी: यह सबसे महत्वपूर्ण हिस्सा है और मैं इसका परीक्षण करना चाहता हूं :)

@ drub0y मुझे आश्चर्य है कि सार्वजनिक पद्धति का उपयोग करना गलत है :)

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

फिर भी, आइए हम उस पर वापस जाएं जो @PureKrome देखना चाहता था कि किसी को अपनी कक्षाओं को HttpClient API डिज़ाइन के साथ फिट करने के लिए कैसे डिज़ाइन करना चाहिए ताकि वे आसानी से अपने कोड का परीक्षण कर सकें।

सबसे पहले, यहां एक उदाहरण डोमेन सेवा है जो अपने डोमेन की जरूरतों को पूरा करने के लिए HTTP कॉल करने जा रही है:

``` सी#
सार्वजनिक इंटरफ़ेस ISomeDomainService
{
टास्कGetSomeThingsValueAsync (स्ट्रिंग आईडी);
}

पब्लिक क्लास SomeDomainService: ISomeDomainService
{
निजी पठनीय HttpClient _httpClient;

public SomeDomainService() : this(new HttpClient())
{

}

public SomeDomainService(HttpClient httpClient)
{
    _httpClient = httpClient;
}

public async Task<string> GetSomeThingsValueAsync(string id)
{
    return await _httpClient.GetStringAsync("/things/" + Uri.EscapeUriString(id));
}

}

As you can see, it allows an `HttpClient` instance to be injected and also has a default constructor that instantiates the default `HttpClient` with no other special settings (obviously this default instance can be customized, but I'll leave that out for brevity).

Ok, so what's a test method look like for this thing using the MockHttp library then? Let's see:

``` c#
[Fact]
public async Task GettingSomeThingsValueReturnsExpectedValue()
{
    // Arrange
    var mockHttpMessageHandler = new MockHttpMessageHandler();
    mockHttpMessageHandler.Expect("http://unittest/things/123")
        .Respond(new StringContent("expected value"));

    SomeDomainService sut = new SomeDomainService(new HttpClient(mockHttpMessageHandler)
    {
        BaseAddress = new Uri("http://unittest")
    });

    // Act
    var value = await sut.GetSomeThingsValueAsync("123");

    // Assert
    value.Should().Be("expected value");
}

अरे, यह बहुत आसान और सीधा है; दिन IMNSHO के रूप में स्पष्ट पढ़ता है। साथ ही, ध्यान दें कि मैं FluentAssertions का लाभ उठा रहा हूं, जो एक और पुस्तकालय है, मुझे लगता है कि हम में से बहुत से लोग उपयोग करते हैं और "मैं एक और पुस्तकालय नहीं लाना चाहता" तर्क के खिलाफ एक और हड़ताल करता हूं।

अब, मैं यह भी बताता हूं कि आप किसी भी उत्पादन कोड के लिए शायद कभी भी _really_ GetStringAsync का उपयोग क्यों नहीं करना चाहेंगे। SomeDomainService::GetSomeThingsValueAsync विधि पर वापस देखें और मान लें कि यह एक आरईएसटी एपीआई कह रहा है जो वास्तव में सार्थक HTTP स्थिति कोड देता है। उदाहरण के लिए, हो सकता है कि "123" की आईडी वाली कोई "चीज़" मौजूद न हो और इसलिए API 404 स्थिति लौटाएगा। इसलिए मैं इसका पता लगाना चाहता हूं और इसे निम्नलिखित डोमेन विशिष्ट अपवाद के रूप में मॉडल करना चाहता हूं:

``` सी#
// क्रमांकन समर्थन संक्षिप्तता के लिए बाहर रखा गया है
सार्वजनिक वर्ग SomeThingDoesntExistException: अपवाद:
{
सार्वजनिक SomeThingDoesntExistException (स्ट्रिंग आईडी)
{
आईडी = आईडी;
}

public string Id
{
    get;
    private set;
}

}

Ok, so let's rewrite the `SomeDomainService::GetSomeThingsValueAsync` method to do that now:

``` c#
public async Task<string> GetSomeThingsValueAsync(string id)
{
    try
    {
        return await _httpClient.GetStringAsync("/things/" + Uri.EscapeUriString(id));
    }
    catch(HttpRequestException requestException)
    {
        // uh, oh... no way to tell if it doesn't exist (404) or server maybe just errored (500)
    }
}

तो मैं यही बात कर रहा था जब मैंने कहा कि GetStringAsync जैसी बुनियादी "सुविधा" विधियां उत्पादन स्तर कोड के लिए वास्तव में "अच्छे" नहीं हैं। आप केवल HttpRequestException प्राप्त कर सकते हैं और वहां से आप यह नहीं बता सकते कि आपको कौन सा स्थिति कोड मिला है और इसलिए संभवतः इसे किसी डोमेन के भीतर सही अपवाद में अनुवादित नहीं किया जा सकता है। इसके बजाय, आपको GetAsync का उपयोग करना होगा और HttpResponseMessage की व्याख्या इस प्रकार करनी होगी:

``` सी#
सार्वजनिक async कार्यGetSomeThingsValueAsync (स्ट्रिंग आईडी)
{
HttpResponseMessage responseMessage = प्रतीक्षा करें _httpClient.GetAsync("/things/" + Uri.EscapeUriString(id));

if(responseMessage.IsSuccessStatusCode)
{
    return await responseMessage.Content.ReadAsStringAsync();
}
else
{
    switch(responseMessage.StatusCode)
    {
        case HttpStatusCode.NotFound:
            throw new SomeThingDoesntExistException(id);

        // any other cases you want to might want to handle specifically for your domain

        default:
            // Unhandled cases can throw domain specific lower level communication exceptions
            throw new HttpCommunicationException(responseMessage.StatusCode, responseMessage.ReasonPhrase);
    }
}

}

Ok, so now let's write a test to validate that I get my domain specific exception when I request a URL that doesn't exist:

``` C#
[Fact]
public void GettingSomeThingsValueForIdThatDoesntExistThrowsExpectedException()
{
    // Arrange
    var mockHttpMessageHandler = new MockHttpMessageHandler();

    SomeDomainService sut = new SomeDomainService(new HttpClient(mockHttpMessageHandler)
    {
        BaseAddress = new Uri("http://unittest")
    });

    // Act
    Func<Task> action = async () => await sut.GetSomeThingsValueAsync("SomeIdThatDoesntExist");

    // Assert
    action.ShouldThrow<SomeThingDoesntExistException>();
}

Ermahgerd यह और भी कम कोड है !!$!% क्यों? 'क्योंकि मुझे MockHttp के साथ एक अपेक्षा भी स्थापित करने की आवश्यकता नहीं थी और इसने मुझे डिफ़ॉल्ट व्यवहार के रूप में अनुरोधित URL के लिए स्वचालित रूप से 404 लौटा दिया।

@PureKrome ने एक ऐसे मामले का भी उल्लेख किया जहां वह एक सेवा वर्ग के भीतर से नए HttpClient उदाहरणों को तुरंत चालू करना चाहता है। जैसा कि मैंने पहले कहा था, उस स्थिति में आप वास्तविक निर्माण से खुद को अलग करने के बजाय एक निर्भरता के रूप में Func<HttpClient> लेंगे या यदि आप Func के प्रशंसक नहीं हैं तो आप अपना खुद का फ़ैक्टरी इंटरफ़ेस पेश कर सकते हैं

मैंने अपना उत्तर हटा दिया - मैं @drub0y के उत्तर और कोड के बारे में थोड़ा सोचना चाहता हूं।

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

@luisrudge ज़रूर, मैं इससे सहमत हो सकता हूं, लेकिन हमने कभी कैसे पता लगाया कि हमें Moq या FakeItEasy की आवश्यकता है? हमने कैसे पता लगाया कि हमें N/XUnit, FluentAssertions, आदि की आवश्यकता है? मैं वास्तव में इसे किसी भिन्न के रूप में नहीं देखता।

वहाँ समुदाय में महान (स्मार्ट) लोग हैं जो इस सामान की आवश्यकता को पहचानते हैं और वास्तव में इन समस्याओं को हल करने के लिए इस तरह के पुस्तकालयों को शुरू करने के लिए समय लेते हैं। (उन सभी को प्रणाम!) तब समाधान जो वास्तव में "अच्छे" होते हैं, उन पर दूसरों का ध्यान जाता है जो समान जरूरतों को पहचानते हैं और समुदाय के अन्य नेताओं द्वारा ओएसएस और सुसमाचार प्रचार के माध्यम से व्यवस्थित रूप से विकसित होने लगते हैं। मुझे लगता है कि इस संबंध में चीजें पहले से कहीं बेहतर हैं क्योंकि ओएसएस की शक्ति अंततः .NET समुदाय में महसूस की जा रही है।

अब, उस ने कहा, मैं व्यक्तिगत रूप से मानता हूं कि माइक्रोसॉफ्ट को कुछ _like_ MockHttp प्रदान करना चाहिए था साथ ही System.Net.Http एपीआई की डिलीवरी "आउट ऑफ द बॉक्स" के साथ। AngularJS टीम ने $httpBackEnd के साथ-साथ $http प्रदान किया क्योंकि उन्होंने माना कि लोगों को अपने ऐप्स का प्रभावी ढंग से परीक्षण करने में सक्षम होने के लिए इस क्षमता की बिल्कुल _ आवश्यकता होगी। मुझे लगता है कि Microsoft _didn't_ इसी समस्या की पहचान करता है, इसलिए इस एपीआई के साथ सर्वोत्तम प्रथाओं के बारे में इतना "भ्रम" है और मुझे लगता है कि हम सभी यहां इसके बारे में चर्चा क्यों कर रहे हैं। :निराश: उस ने कहा, मुझे खुशी है कि @richardszalay और @PureKrome ने अपने पुस्तकालयों के साथ उस अंतर को भरने की कोशिश करने के लिए प्लेट में कदम रखा है और अब मुझे लगता है कि हमें उनके पुस्तकालयों को बेहतर बनाने में मदद करने के लिए उनके पीछे जाना चाहिए, हालांकि हम सभी को बनाने के लिए कर सकते हैं हमारे जीवन की आसान। :मुस्कुराओ:

अभी इस सूत्र के बारे में सूचित किया गया है, तो सोचा कि मैं अपना 2c अंदर फेंक दूंगा।

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

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

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

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

मुझे इसका मज़ाक उड़ाना पसंद है लेकिन हम Func हस्ताक्षर का भी उपयोग करते हैं:

public static async Task<T> GetWebObjectAsync<T>(Func<string, Task<string>> getHtmlAsync, string url)
{
    var html = await getHtmlAsync(url);
    var info = JsonConvert.DeserializeObject<T>(html);
    return info;
}

यह टेस्ट क्लास कोड को इतना आसान बनाने की अनुमति देता है:

Func<string, Task<string>> getHtmlAsync = u => Task.FromResult(EXPECTED_HTML);
var result = controller.InternalCallTheWeb(getHtmlAsync);

और नियंत्रक बस कर सकता है:

public static HttpClient InitHttpClient()
{
    return _httpClient ?? (_httpClient = new HttpClient(new WebRequestHandler
    {
        CachePolicy = new HttpRequestCachePolicy(HttpCacheAgeControl.MaxAge, new TimeSpan(0, 1, 0)),
        Credentials = new NetworkCredential(PublishingCredentialsUserName, PublishingCredentialsPassword)
    }, true));
}

[Route("Information")]
public async Task<IHttpActionResult> GetInformation()
{
    var httpClient = InitHttpClient();
    var result = await InternalCallTheWeb(async u => await httpClient.GetStringAsync(u));
    ...
}

लेकिन वे इसे थोड़ा आसान बना सकते हैं... :)

हाय .NET टीम! बस इस मुद्दे पर आधार को छू रहा है। इस चर्चा के बारे में टीम क्या सोचती है, इस बारे में अभी एक महीने + के आसपास हो गया है और किसी भी विचार के लिए उत्सुक है।

शिविर के दोनों ओर से विभिन्न बिंदु हैं - सभी दिलचस्प और प्रासंगिक आईएमओ।

क्या आप लड़कियों/दोस्तों से कोई अपडेट हैं?

अर्थात।

1. हम कॉनवो पढ़ रहे हैं और कुछ भी नहीं बदलेंगे। आपके इनपुट के लिए धन्यवाद, आपका दिन शुभ हो। यहां, केक का एक टुकड़ा लें:
2. हमने ईमानदारी से इसके बारे में नहीं सोचा है (जैसा कि आप कल्पना कर सकते हैं, चीजें यहां व्यस्त हैं) _but_ इसके बारे में बाद की तारीख में सोचेंगे _ इससे पहले कि हम रिलीज-टू-वेब (आरटीडब्ल्यू) पर जाएं।
3. दरअसल, हमने इसके बारे में कुछ आंतरिक चर्चा की है और हम स्वीकार करते हैं कि जनता को इसे टटोलना थोड़ा दर्दनाक लग रहा है। इसलिए हम सोच रहे हैं कि हम XXXXXXXXX कर सकते हैं।

टा!

यह भाग 2 और 3 है।

परीक्षण में सहायता के लिए "नकली" हैंडलर डालने की क्षमता को सरल बनाने का एक तरीका एचटीपी क्लाइंट, यानी HttpClient.DefaultHandler में एक स्थिर विधि को जोड़ा जाना है। डिफ़ॉल्ट HttpClient() कंस्ट्रक्टर को कॉल करते समय यह स्थिर विधि डेवलपर्स को वर्तमान HttpClientHandler की तुलना में एक अलग डिफ़ॉल्ट हैंडलर सेट करने की अनुमति देगी। "नकली" नेटवर्क के खिलाफ परीक्षण में मदद करने के अलावा, यह उन डेवलपर्स की मदद करेगा जो एचटीपी क्लाइंट के ऊपर पोर्टेबल पुस्तकालयों में कोड लिखते हैं, जहां वे सीधे एचटीपी क्लाइंट इंस्टेंस नहीं बनाते हैं। तो, यह उन्हें इस वैकल्पिक डिफ़ॉल्ट हैंडलर को "इंजेक्ट" करने की अनुमति देगा।

तो, यह उस चीज़ का एक उदाहरण है जिसे हम वर्तमान ऑब्जेक्ट मॉडल में जोड़ सकते हैं जो कि योगात्मक होगा और वर्तमान आर्किटेक्चर में एक ब्रेकिंग परिवर्तन नहीं होगा।

बहुत ही शीघ्र उत्तर के लिए धन्यवाद @davidsh : +1:

मैं खुशी-खुशी प्रतीक्षा करूँगा और इस स्थान को देखूँगा क्योंकि यह जानना रोमांचक है कि यह भाग 1 नहीं है: मुस्कान: .. और जो कुछ भी होता है उसे देखने के लिए उत्सुक: +1:

आपके धैर्य और सुनने के लिए फिर से धन्यवाद (टीम) - वास्तव में इसकी सराहना करते हैं!

/ मुझे खुशी से इंतजार है।

@ डेविड तो, इंटरफ़ेस ओएस वर्चुअल विधियां प्रश्न से बाहर हैं?

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

आभासी तरीकों के बारे में क्या?

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

/me इस थ्रेड पर Resurrection कास्ट करता है...

~ धागा मुड़ता है, कराहता है, मरोड़ता है और जिंदा आता है!

बस अगस्त 20 वीं 2015 सामुदायिक स्टैंडअप सुन रहा था और उन्होंने उल्लेख किया कि एचटीपी क्लाइंट बीटा 7 के साथ क्रॉस प्लेट का लाभ उठाएगा। वाह!

तो... क्‍या इस पर कोई निर्णय लिया गया है? या तो सुझाव नहीं दे रहा/या .. बस विनम्रता से किसी चर्चा अपडेट आदि के लिए पूछ रहा हूं?

@PureKrome इस पर कोई निर्णय नहीं लिया गया है लेकिन यह एपीआई डिजाइन/जांच कार्य हमारी भविष्य की योजनाओं में शामिल है। अभी, हम में से अधिकांश का ध्यान शेष System.Net कोड को GitHub पर प्राप्त करने और क्रॉस-प्लेटफ़ॉर्म पर काम करने पर केंद्रित है। इसमें मौजूदा स्रोत कोड और हमारे परीक्षणों को Xunit ढांचे में पोर्ट करना दोनों शामिल हैं। एक बार जब यह प्रयास अभिसरण हो जाता है, तो टीम के पास भविष्य में होने वाले परिवर्तनों पर ध्यान केंद्रित करने के लिए अधिक समय होगा, जैसा कि इस सूत्र में सुझाया गया है।

धन्यवाद ढेर @davidsh - मैं वास्तव में उत्तर देने के लिए आपके समय की सराहना करता हूं :) बढ़िया काम जारी रखें! गुब्बारा:

http सेवाओं के परीक्षण के लिए मॉक का उपयोग थोड़ा अप्रचलित नहीं कर रहा है? कुछ स्वयं होस्टिंग विकल्प हैं जो http सेवा का आसान मजाक बनाने की अनुमति देते हैं और इसके लिए किसी कोड परिवर्तन की आवश्यकता नहीं होती है, केवल सेवा url में परिवर्तन की आवश्यकता होती है। यानी HttpListener और OWIN स्वयं होस्ट, लेकिन जटिल API के लिए कोई नकली सेवा भी बना सकता है या ऑटोरेस्पोन्डर का उपयोग कर सकता है।

इस HttpClient वर्ग की इकाई-परीक्षण-क्षमता पर कोई अद्यतन? मैं DeleteAsync विधि का मजाक उड़ाने की कोशिश कर रहा हूं, लेकिन जैसा कि पहले उल्लेख किया गया है कि Moq शिकायत कर रहा है कि फ़ंक्शन वर्चुअल नहीं है। ऐसा लगता है कि अपना खुद का रैपर बनाने के अलावा कोई आसान तरीका नहीं है।

मैं रिचर्ड्सज़ाले को वोट देता हूँ।मॉकhttp!
उत्कृष्ट है! सरल और शानदार!

https://github.com/richardszalay/mockhttp

लेकिन @YehudahA - हमें इसकी आवश्यकता नहीं होनी चाहिए .... (यही इस कॉनवो की बात है) :)

@PureKrome हमें IHttpClient की आवश्यकता नहीं है।
यह ईएफ 7 जैसा ही विचार है। आप कभी भी आईडीबीकॉन्टेक्स्ट या आईडीबीसेट का उपयोग नहीं करते हैं, लेकिन आप डीबीकॉन्टेक्स्टऑप्शन का उपयोग करके व्यवहार को बदलते हैं।

Richardszalay.MockHttp एक आउट-ऑफ़-द-बॉक्स समाधान है।

यह एक आउट-ऑफ-द-बॉक्स समाधान है।

हमें IHttpClient की आवश्यकता नहीं है।
यह ईएफ 7 के समान विचार है। आप कभी भी आईडीबीकॉन्टेक्स्ट या आईडीबीसेट का उपयोग नहीं करते हैं, लेकिन आप डीबीकॉन्टेक्स्टऑप्शन का उपयोग करके व्यवहार को बदलते हैं।

यह ठीक है - मैं पूरी तरह असहमत हूं, इसलिए हम असहमत होने के लिए सहमत हैं।

क्या दोनों तरीके काम करते हैं? हां। कुछ लोग (मेरे जैसे) खोज योग्यता और पठनीयता और सरलता जैसे कारणों से एक इंटरफ़ेस या वर्चुअल विधि EASIER का मज़ाक उड़ाते हुए पाते हैं।

अन्य (अपने आप की तरह) व्यवहार में हेरफेर करना पसंद करते हैं। मुझे लगता है कि यह अधिक जटिल, खोजने में कठिन और अधिक समय लेने वाला है। (जो (मेरे लिए) समर्थन/बनाए रखने के लिए कठिन अनुवाद करता है)।

प्रत्येक के लिए उनके अपने मेरा अंदाज़ा है :)

रिचर्ड्सज़ाले कहते हैं: "यह पैटर्न एंगुलरजेएस के $httpBackend से काफी प्रेरित है"।
सही बात है। यहां देखें: https://docs.angularjs.org/api/ngMock/service/ $httpBackend

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

        private static IDisposable FakeService(string uri, string response)
        {
            var httpListener = new HttpListener();
            httpListener.Prefixes.Add(uri);

            httpListener.Start();

            httpListener.GetContextAsync().ContinueWith(task =>
            {
                var context = task.Result;

                var buffer = Encoding.UTF8.GetBytes(response);

                context.Response.OutputStream.Write(buffer, 0, buffer.Length);

                context.Response.OutputStream.Close();
            });

            return httpListener;
        }

उपयोग:

            var uri = "http://localhost:8888/myservice/";
            var fakeResponse = "Hello World";

            using (FakeService(uri, fakeResponse))
            {
                // Run your test here ...

                // This is only to test that is really working:
                using (var client = new HttpClient())
                {
                    var result = client.GetStringAsync(uri).Result;
                }
            }

@metzgithub यहां सबसे अच्छा है, क्योंकि यह लक्ष्य सेवा के व्यवहार के उचित अनुकरण की अनुमति देता है।

यह वही है जो मैं ढूंढ रहा था क्योंकि यह मुझे 'दुर्भावनापूर्ण/दुर्भावनापूर्ण' डेटा डालने के लिए सही जगह देता है (सुरक्षा और गैर-खुश पथ परीक्षणों के लिए)

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

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

मैं टेस्ट ड्रिवेन डेवलपमेंट के तत्कालीन अपेक्षाकृत नए अभ्यास को अपनाने के दौरान लगभग एक दशक पहले सीखी गई टेस्टेबिलिटी की परिभाषा का उपयोग करना चुनता हूं:

"एक वर्ग परीक्षण योग्य है यदि इसे इसके सामान्य वातावरण से हटाया जा सकता है और तब भी काम करता है जब इसकी सभी निर्भरताएं इंजेक्ट की जाती हैं"

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

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

इसलिए मेरे पास इन मामलों में अपने सामान्य समाधान का सहारा लेने और एक हल्का एडेप्टर/रैपर लाइब्रेरी बनाने का विकल्प बचा है जो मुझे एक इंटरफ़ेस देता है और मुझे मेरे द्वारा चुने गए तरीके से काम करने की अनुमति देता है।

मुझे पार्टी में भी थोड़ी देर हो गई है, लेकिन पिछली सभी टिप्पणियों को पढ़ने के बाद भी, मुझे अभी भी यकीन नहीं है कि कैसे आगे बढ़ना है। क्या आप कृपया मुझे बता सकते हैं कि मैं सार्वजनिक एपीआई पर टेस्ट कॉल विशेष एंडपॉइंट्स के तहत अपने ऑब्जेक्ट में उस विशेष तरीके को कैसे सत्यापित करूं? मुझे परवाह नहीं है कि क्या वापस आता है। मैं बस यह सुनिश्चित करना चाहता हूं कि जब कोई मेरे ApiClient वर्ग के उदाहरण पर "GoGetSomething" कहता है, तो वह " https://somenifty.com/api/something " पर एक GET भेजता है। मैं क्या करना चाहता हूं (कोड काम नहीं कर रहा है):

Mock<HttpClient> mockHttpClient = new Mock<HttpClient>();
mockHttpClient.Setup(x => x.SendAsync(It.IsAny<HttpRequestMessage>())).Verifiable();
ApiClient client = new ApiClient(mockHttpClient.Object);

Something response = await client.GoGetSomething();
mockHttpClient
    .Verify(x => x.SendAsync(
        It.Is<HttpRequestMessage>(m =>
            m.Method.Equals(HttpMethod.Get) &&
            m.RequestUri.Equals("https://somenifty.com/api/something"))));

लेकिन, यह मुझे SendAsync का मजाक नहीं बनने देता।

अगर मैं उस मूल चीज को काम कर सकता हूं, तो मैं वास्तव में यह जांचना चाहता हूं कि मेरी कक्षा उस कॉल से विशेष रिटर्न कैसे संभालती है।

कोई विचार? यह (मेरे लिए) ऐसा प्रतीत नहीं होता है कि परीक्षण करने के लिए बहुत अधिक अजीब चीज है।

लेकिन, यह मुझे SendAsync का मजाक नहीं बनने देता।

आप HttpClient.SendAsync पद्धति का मजाक नहीं उड़ाते हैं।

इसके बजाय आप HttpMessageHandler से प्राप्त एक नकली हैंडलर बनाते हैं। फिर आप उस की SendAsync विधि को ओवरराइड करते हैं। फिर आप उस हैंडलर ऑब्जेक्ट को HttpClient के निर्माता में पास करते हैं।

@jdcrutchley , आप इसे @richardszalay के MockHttp के साथ कर सकते हैं।

public class MyApiClient
{
    private readonly HttpClient httpClient;

    public MyApiClient(HttpMessageHandler handler)
    {
        httpClient = new HttpClient(handler, disposeHandler: false);
    }

    public async Task<HttpStatusCode> GoGetSomething()
    {
        var response = await httpClient.GetAsync("https://somenifty.com/api/something");
        return response.StatusCode;
    }
}

[TestMethod]
public async Task MyApiClient_GetSomething_Test()
{
    // Arrange
    var mockHandler = new MockHttpMessageHandler();
    mockHandler.Expect("https://somenifty.com/api/something")
        .Respond(HttpStatusCode.OK);

    var client = new MyApiClient(mockHandler);

    // Act
    var response = await client.GoGetSomething();

    // Assert
    Assert.AreEqual(response, HttpStatusCode.OK);
    mockHandler.VerifyNoOutstandingExpectation();
}

@jdcrutchley या आप एक विधि SendAsync के साथ अपना स्वयं का रैपर वर्ग और रैपर इंटरफ़ेस बनाते हैं .. जो केवल _real_ httpClient.SendAsync (आपके रैपर वर्ग में) को कॉल करता है।

मैं अनुमान लगा रहा हूं कि @richardszalay का MockHttp यही कर रहा है।

यह सामान्य पैटर्न है जो लोग तब करते हैं जब वे किसी चीज़ का मज़ाक नहीं उड़ा सकते (क्योंकि कोई इंटरफ़ेस नहीं है या यह आभासी नहीं है)।

मॉकhttp HttpMessageHandler पर एक नकली DSL है। यह Moq का उपयोग करके गतिशील रूप से इसका मजाक उड़ाने से अलग नहीं है, लेकिन DSL के कारण इरादा स्पष्ट है।

अनुभव किसी भी तरह से समान है: HttpMessageHandler का मजाक उड़ाएं और इससे एक ठोस HttpClient बनाएं। आपका डोमेन घटक या तो HttpClient या HttpMessageHandler पर निर्भर करता है।

संपादित करें: टीबीएच, मुझे पूरी तरह से यकीन नहीं है कि मौजूदा डिज़ाइन में क्या समस्या है। "मॉकेबल एचटीपी क्लाइंट" और "मॉकेबल एचटीपीमेसेजहैंडलर" के बीच का अंतर सचमुच आपके परीक्षण में कोड की एक पंक्ति है: new HttpClient(mockHandler) , और इसका लाभ यह है कि कार्यान्वयन "प्रति प्लेटफॉर्म अलग कार्यान्वयन" और " परीक्षण के लिए अलग कार्यान्वयन" (यानी परीक्षण कोड के प्रयोजनों के लिए दागी नहीं है)।

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

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

मुझे यह जानकर भी आश्चर्य हुआ कि HttpClient ने आसान मॉकिंग के लिए एक इंटरफ़ेस लागू नहीं किया। मैंने वेब के चारों ओर खोज की, यह धागा पाया, और आगे बढ़ने से पहले इसे शुरू से अंत तक पढ़ा। @ Drub0y के उत्तर ने मुझे HttpMessageHandler का मजाक उड़ाने के मार्ग पर आगे बढ़ने के लिए आश्वस्त किया।

मेरी पसंद का मज़ाक करने वाला ढांचा Moq है, शायद .NET देवों के लिए काफी मानक है। सुरक्षित SendAsync विधि को सेटअप और सत्यापित करने की कोशिश के साथ Moq API से लड़ने में एक घंटे के करीब खर्च करने के बाद, मैंने अंततः Moq में संरक्षित जेनेरिक विधियों की पुष्टि के साथ एक बग मारा। यहां देखें।

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

यह एक उत्कृष्ट बिंदु है केन, मैं भूल गया था कि HttpMessageHandler.SendAsync संरक्षित था।

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

इंटरफ़ेस के लिए +1।

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

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

मैं शायद अपना खुद का रैपर बनाने का मार्ग जाऊंगा। क्योंकि बाहर से देखने पर, यह किसी को समझ में नहीं आने वाला है कि मैंने अपनी कक्षा में HttpMessageHandler को क्यों इंजेक्ट किया।

यदि HttpClient के लिए एक इंटरफ़ेस बनाना संभव नहीं है - तो शायद .net टीम एक बिल्कुल नया http समाधान बना सकती है जिसमें एक इंटरफ़ेस हो?

@ स्कॉट-मार्टिन, HttpClient कुछ भी नहीं करता है, वह सिर्फ अनुरोध भेजता है HttpMessageHandler ।

HttpClient का परीक्षण करने के बजाय आप HttpMessageHandler का परीक्षण और नकल कर सकते हैं। यह बहुत आसान है, और आप Richardszalay mockhttp का भी उपयोग कर सकते हैं।

@ स्कॉट-मार्टिन जैसा कि केवल कुछ टिप्पणियों का उल्लेख किया गया था, आप HttpMessageHandler इंजेक्ट नहीं करते हैं। जब आप यूनिट परीक्षण कर रहे हों तो आप HttpClient इंजेक्ट करते हैं, और HttpMessageHandler के साथ _that_ इंजेक्ट करते हैं।

@richardszalay टिप के लिए धन्यवाद, जो मेरे कार्यान्वयन से निम्न-स्तरीय अमूर्तता को दूर रखने में बेहतर काम करता है।

@YehudahA , मैं HttpMessageHandler का मज़ाक उड़ाकर इसे काम करने में सक्षम था। लेकिन "इसे काम करना" इसलिए नहीं है कि मैंने चिल्लाया। जैसा कि @PureKrome ने कहा, यह खोज-क्षमता की समस्या है। यदि कोई इंटरफ़ेस होता, तो मैं उसका मज़ाक उड़ा पाता और कुछ ही मिनटों में अपने रास्ते पर आ जाता। क्योंकि वहाँ एक नहीं है, मुझे समाधान खोजने में कई घंटे बिताने पड़े।

मैं एक इंटरफ़ेस प्रदान करने की सीमाओं और झिझक को समझता हूं। मैं केवल समुदाय के एक सदस्य के रूप में अपनी प्रतिक्रिया देना चाहता हूं कि हमें इंटरफेस पसंद हैं और कृपया हमें उनमें से अधिक दें - उनके साथ बातचीत करना और उनके खिलाफ परीक्षण करना बहुत आसान है।

यह खोज-क्षमता की समस्या है। अगर कोई इंटरफ़ेस होता, तो मैं उसका मज़ाक उड़ा पाता और कुछ ही मिनटों में अपने रास्ते पर आ जाता । क्योंकि वहाँ एक नहीं है, मुझे समाधान खोजने में कई घंटे बिताने पड़े।

: एरो_अप: यह। यह सब के बारे में है, यह।

संपादित करें: जोर, मेरा।

जबकि मैं पूरी तरह से सहमत हूं कि यह अधिक खोज योग्य हो सकता है, मुझे यकीन नहीं है कि इसमें "कई घंटे" कैसे लग सकते हैं। गुगलिंग "मॉक httpclient" इस स्टैक ओवरफ्लो प्रश्न को पहले परिणाम के रूप में लाता है, जिसमें दो उच्चतम रेटेड उत्तर (हालांकि, स्वीकृत उत्तर नहीं) HttpMessageHandler का वर्णन करते हैं।

एनपी - हम अभी भी असहमत होने के लिए सहमत हैं। टिस ऑल गुड :)

आप इस मुद्दे को बंद कर सकते हैं, क्योंकि mscorlib अपने सभी सामान के साथ वापस आ रहा है :)

क्या हम सिर्फ इन httpclient वर्गों को एक इंटरफ़ेस लागू कर सकते हैं? फिर बाकी से अपने आप निपट सकते हैं।

DI सेवा में प्रयुक्त HttpClient का उपहास करने के लिए आप किस समाधान का प्रस्ताव करते हैं?
मैं एक FakeHttpClientHandler को लागू करने का प्रयास कर रहा हूं और मुझे नहीं पता कि SendAsync विधि के साथ क्या करना है।

मेरे पास एक साधारण जियोलोकेशन सर्विस है जो एक दूसरे से आईपी आधारित स्थान की जानकारी प्राप्त करने के लिए एक माइक्रोसर्विस को कॉल करती है। मैं नकली HttpClientHandler को सेवा में पास करना चाहता हूं, जिसमें दो रचनाकार हैं, एक स्थान प्राप्त कर रहा है सेवा पता और एक स्थान सेवा पता और अतिरिक्त HttpClientHandler के साथ।

public class GeoLocationService: IGeoLocationService {

        private readonly string _geoLocationServiceAddress;
        private HttpClient _httpClient;
        private readonly object _gate = new object();

        /// <summary>
        /// Creates a GeoLocation Service Instance for Dependency Injection
        /// </summary>
        /// <param name="locationServiceAddress">The GeoLocation Service Hostname (IP Address), including port number</param>
        public GeoLocationService(string locationServiceAddress) {
            // Add the ending slash to be able to GetAsync with the ipAddress directly
            if (!locationServiceAddress.EndsWith("/")) {
                locationServiceAddress += "/";
            }

            this._geoLocationServiceAddress = locationServiceAddress;
            this._httpClient = new HttpClient {
                BaseAddress = new Uri(this._geoLocationServiceAddress)
            };
        }

        /// <summary>
        /// Creates a GeoLocation Service Instance for Dependency Injection (additional constructor for Unit Testing the Service)
        /// </summary>
        /// <param name="locationServiceAddress">The GeoLocation Service Hostname (IP Address), including port number.</param>
        /// <param name="clientHandler">The HttpClientHandler for the HttpClient for mocking responses in Unit Tests.</param>
        public GeoLocationService(string locationServiceAddress, HttpClientHandler clientHandler): this(locationServiceAddress) {
            this._httpClient.Dispose();
            this._httpClient = new HttpClient(clientHandler) {
                BaseAddress = new Uri(this._geoLocationServiceAddress)
            };
        }

        /// <summary>
        /// Geo Location Microservice Http Call with recreation of HttpClient in case of failure
        /// </summary>
        /// <param name="ipAddress">The ip address to locate geographically</param>
        /// <returns>A <see cref="string">string</see> representation of the Json Location Object.</returns>
        private async Task<string> CallGeoLocationServiceAsync(string ipAddress) {
            HttpResponseMessage response;
            string result = null;

            try {
                response = await _httpClient.GetAsync(ipAddress);

                response.EnsureSuccessStatusCode();

                result = await response.Content.ReadAsStringAsync();
            }
            catch (Exception ex) {
                lock (_gate) {
                    _httpClient.Dispose(); 
                    _httpClient = new HttpClient {
                        BaseAddress = new Uri(this._geoLocationServiceAddress)
                    };
                }

                result = null;

                Logger.LogExceptionLine("GeoLocationService", "CallGeoLocationServiceAsync", ex.Message, stacktrace: ex.StackTrace);
            }

            return result;
        }

        /// <summary>
        /// Calls the Geo Location Microservice and returns the location description for the provided IP Address. 
        /// </summary>
        /// <param name="ipAddress">The <see cref="string">IP Address</see> to be geographically located by the GeoLocation Microservice.</param>
        /// <returns>A <see cref="string">string</see> representing the json object location description. Does two retries in the case of call failure.</returns>
        public async Task<string> LocateAsync(string ipAddress) {
            int noOfRetries = 2;
            string result = "";

            for (int i = 0; i < noOfRetries; i ++) {
                result = await CallGeoLocationServiceAsync(ipAddress);

                if (result != null) {
                    return result;
                }
            }

            return String.Format(Constants.Location.DefaultGeoLocationResponse, ipAddress);
        }

        public void Dispose() {
            _httpClient.Dispose();
        }

    }

टेस्ट क्लास में, मैं FakeClientHandler नामक एक आंतरिक वर्ग लिखना चाहता हूं जो HttpClientHandler को बढ़ाता है, जो SendAsync विधि को ओवरराइड करता है। एक और तरीका, मुझे लगता है, HttpClientHandler का नकल करने के लिए एक नकली ढांचे का उपयोग करना होगा। मुझे अभी तक नहीं पता कि यह कैसे करना है। अगर आप मदद कर सकते हैं, तो मैं हमेशा आपके कर्ज में रहूंगा।

public class GeoLocationServiceTests {

        private readonly IConfiguration _configuration;
        private IGeoLocationService _geoLocationService;
        private HttpClientHandler _clientHandler;

        internal class FakeClientHandler : HttpClientHandler {

            protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) {

                // insert implementation here

                // insert fake responses here. 
                return (Task<HttpResponseMessage>) null;
            }

        }

        public GeoLocationServiceTests() {
            this._clientHandler = new FakeClientHandler();
            this._clientHandler.UseDefaultCredentials = true;
            this._geoLocationService = new GeoLocationService("http://fakegeolocation.com/json/", this._clientHandler);
        }


        [Fact]
        public async void RequestGeoLocationFromMicroservice() {
            string ipAddress = "192.36.1.252";

            string apiResponse = await this._geoLocationService.LocateAsync(ipAddress);
            Dictionary<string, string> result = JsonConvert.DeserializeObject<Dictionary<string,string>>(apiResponse);

            Assert.True(result.ContainsKey("city"));

            string timeZone;
            result.TryGetValue("time_zone", out timeZone);

            Assert.Equal(timeZone, @"Europe/Stockholm");
        }

        [Fact]
        public async void RequestBadGeoLocation() {
            string badIpAddress = "asjldf";

            string apiResponse = await this._geoLocationService.LocateAsync(badIpAddress);
            Dictionary<string, string> result = JsonConvert.DeserializeObject<Dictionary<string, string>>(apiResponse);

            Assert.True(result.ContainsKey("city"));

            string city;
            result.TryGetValue("city", out city);
            Assert.Equal(city, "NA");

            string ipAddress;
            result.TryGetValue("ip", out ipAddress);
            Assert.Equal(badIpAddress, ipAddress);
        }
    }

@danielmihai HttpMessageHandler प्रभावी रूप से "कार्यान्वयन" है। आप आम तौर पर एक एचटीपी क्लाइंट बनाते हैं, हैंडलर को कंडक्टर में पास करते हैं, और फिर आपकी सेवा परत एचटीपी क्लाइंट पर निर्भर करती है।

सामान्य मॉकिंग फ्रेमवर्क का उपयोग करना कठिन है क्योंकि अतिदेय SendAsync सुरक्षित है। मैंने विशेष रूप से उस कारण से मॉकhttp लिखा था (लेकिन यह भी क्योंकि डोमेन-विशिष्ट मॉकिंग फीचर्स होना अच्छा है।

@danielmihai रिचर्ड ने जो कहा वह _pain_ को काफी हद तक बताता है, हम सभी को एचटीपी क्लाइंट का मज़ाक उड़ाते हुए अभी सहना होगा।

HttpClient.Helpers as _another_ लाइब्रेरी भी है जो आपको HttpClient का मज़ाक उड़ाने में मदद करती है .. या अधिक विशेष रूप से, नकली HttpMessageHandler प्रदान करती है ताकि आप प्रतिक्रियाओं को नकली बना सकें।

मैंने इसे समझ लिया है, कुछ इस तरह लिखा है... [मुझे लगता है कि मैंने 'दर्द' से निपटा है]

internal class FakeClientHandler : HttpClientHandler {
            protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) {
                if (request.Method == HttpMethod.Get) {
                    if (request.RequestUri.PathAndQuery.Contains("/json/")) {
                        string requestPath = request.RequestUri.PathAndQuery;
                        string[] splitPath = requestPath.Split(new char[] { '/' });
                        string ipAddress = splitPath.Last();

                        // RequestGeoLocationFromMicroservice
                        if (ipAddress.Equals(ipAddress1)) {
                            var response = new HttpResponseMessage(HttpStatusCode.OK);
                            response.Content = new StringContent(response1);

                            return Task.FromResult(response);
                        }

                        // RequestBadGeoLocation
                        if (ipAddress.Equals(ipAddress2)) {
                            var response = new HttpResponseMessage(HttpStatusCode.OK);
                            response.Content = new StringContent(response2);
                            return Task.FromResult(response);
                        }
                    }
                }
                return (Task<HttpResponseMessage>) null;
            }
        }

सभी परीक्षण पास

कृपया कार्यान्वयन पर टिप्पणी करें, अगर इसे करने के बेहतर तरीके हैं।

धन्यवाद!

एक साल से अधिक पुरानी चर्चा में अपने विचार जोड़ रहा हूं।

@SidharthNabar

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

जब मैं using स्टेटमेंट का उपयोग नहीं करने वाला हूं, लेकिन new मेरे HttpClient उदाहरण जैसे उपभोक्ता के कंस्ट्रक्टर में मैं गैर-इंजेक्शन इंस्टेंस का निपटान कहां करूं? HttpMessageHandler के बारे में क्या है जिसे मैं HttpClient उदाहरण में इंजेक्शन लगाने के लिए बना रहा हूं?

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

@richardszalay

जबकि मैं पूरी तरह से सहमत हूं कि यह अधिक खोज योग्य हो सकता है, मुझे यकीन नहीं है कि इसमें "कई घंटे" कैसे लग सकते हैं। गुगलिंग "मॉक httpclient" इस स्टैक ओवरफ्लो प्रश्न को पहले परिणाम के रूप में लाता है, जिसमें दो उच्चतम रेटेड उत्तर (हालांकि, स्वीकृत उत्तर नहीं) HttpMessageHandler का वर्णन करते हैं।

डॉक्स, आईएमएचओ के माध्यम से ब्राउज़िंग के साथ उपयोग करने के लिए एक एपीआई सहज होना चाहिए। Google या SO प्रश्न पूछना निश्चित रूप से सहज नहीं है, .NET कोर से पहले से जुड़ा हुआ प्रश्न अप-टू-डेटनेस को स्पष्ट नहीं करता है (हो सकता है कि प्रश्न और _new_ ढांचे के जारी होने के बीच कुछ बदल गया हो?)

उन सभी को धन्यवाद जिन्होंने अपने कोड उदाहरण जोड़े हैं और सहायक कार्य प्रदान किए हैं!

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

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

चूंकि http क्लाइंट इंटरफेस नहीं है, इसलिए हम इसे कंटेनर से इंजेक्ट नहीं कर सकते हैं।

@dasjestyr हम इंटरफेस के बिना निर्भरता इंजेक्शन कर सकते हैं। इंटरफेस कई विरासत को सक्षम करते हैं; वे निर्भरता इंजेक्शन के लिए एक आवश्यकता नहीं हैं।

हाँ, DI यहाँ मुद्दा नहीं है। इसका मज़ाक उड़ाना कितना आसान/अच्छा है, आदि।

@shaunluttin मुझे पता है कि हम इंटरफ़ेस के बिना DI कर सकते हैं, मैंने अन्यथा इसका मतलब नहीं था; मैं उस वर्ग के बारे में बात कर रहा हूं जिस पर एचटीपी क्लाइंट पर निर्भरता है। क्लाइंट के लिए इंटरफ़ेस के बिना, मैं एक नकली http क्लाइंट या किसी भी http क्लाइंट को इंजेक्ट नहीं कर सकता (ताकि इसे वास्तविक http कॉल किए बिना अलगाव में परीक्षण किया जा सके) जब तक कि मैं इसे एक एडेप्टर में लपेटता हूं जो एक इंटरफ़ेस लागू करता है जिसे मैं ' ve HttpClient की नकल करने के लिए परिभाषित करते हैं। मैंने स्पष्टता के लिए कुछ शब्दों को थोड़ा बदल दिया है यदि आप एक वाक्य पर फिक्सिंग कर रहे थे।

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

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

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

यह इस मुद्दे का दिल/मूल है -> और यह _purely_ भी माना जाता है।

बाड़ के एक तरफ: नकली संदेश हैंडलर क्योंकि <insert their rational here>
बाड़ के दूसरी तरफ: <insert their rational here> की वजह से इंटरफेस (या यहां तक ​​​​कि आभासी विधियां, लेकिन वह अभी भी एक पिटा का एक छोटा सा हिस्सा है)।

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

मुझे वास्तव में मेरी कक्षाओं में से एक पर इसका परीक्षण करना पड़ा। ऐसा करने के लिए, मुझे नकली हैंडलर में एक संचयक जोड़ना पड़ा जो हर बार SendAsync() विधि को कॉल करने पर बढ़ता गया। वह एक साधारण मामला था, शुक्र है, लेकिन चलो। इस बिंदु पर मॉकिंग व्यावहारिक रूप से एक मानक है।

हाँ - यहाँ आपसे पूरी तरह सहमत हूँ

कृपया, माइक्रोसॉफ्ट, IHttpClient , अवधि जोड़ें। या सुसंगत रहें और बीसीएल - IList , IDictionary , ICollection में अपने सभी इंटरफेस को हटा दें, क्योंकि वे वैसे भी "संस्करण के लिए कठिन" हैं। बिल्ली, IEnumerable से भी छुटकारा पाएं।

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

@lasseschou IList , IDictionary , ICollection और IEnumerable पूरी तरह से महत्वपूर्ण हैं क्योंकि उन्हें लागू करने वाली विभिन्न प्रकार की कक्षाएं हैं। IHttpClient केवल HttpClient द्वारा लागू किया जाएगा - आपके तर्क के अनुरूप होने के लिए, बीसीएल में प्रत्येक वर्ग को एक इंटरफ़ेस प्रकार देना होगा क्योंकि हमें इसका मजाक उड़ाने की आवश्यकता हो सकती है।
मुझे इस तरह की अव्यवस्था देखकर दुख होगा।

जब तक कोई नाटकीय ट्रेडऑफ़ न हो, IHttpClient किसी भी तरह मजाक करने के लिए गलत अमूर्त स्तर है। आपका ऐप लगभग निश्चित रूप से एचटीपी क्लाइंट की क्षमताओं की पूरी श्रृंखला का प्रयोग नहीं करेगा। मेरा सुझाव है कि आप अपने ऐप के विशिष्ट अनुरोधों के संदर्भ में अपनी सेवा में HttpClient लपेटें और अपनी स्वयं की सेवा का मजाक उड़ाएं।

@ jnm2 - ब्याज से बाहर, आपको क्यों लगता है कि IHttpClient मजाक करने के लिए गलत अमूर्त स्तर है?

मैं नफरत या ट्रोलिंग नहीं कर रहा हूं - ईमानदार Q.

(सीखना पसंद है, आदि)।

मैं एक ही बात पूछने वाला था क्योंकि यह एक ग्राहक के रूप में देखकर एक आदर्श स्तर का अमूर्तता है।

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

इसके अलावा, मैं "नेवर मॉक ए टाइप यू नॉट ओन ओन" सिद्धांत की सदस्यता लेता हूं, इसलिए वाईएमएमवी।
यह भी देखें http://martinfowler.com/articles/mocksArentStubs.html शास्त्रीय परीक्षण बनाम मॉकिंग की तुलना करना।

यहाँ मुद्दा यह है कि HttpClient इतनी बड़ी प्रगति है
WebClient, XMLHttpRequest, कि यह HTTP करने का पसंदीदा तरीका बन गया है
कॉल। यह स्वच्छ और आधुनिक है। मैं हमेशा नकली एडेप्टर का उपयोग करता हूं जो बात करते हैं
सीधे एचटीपी क्लाइंट पर, इसलिए मेरे कोड का परीक्षण करना आसान है। लेकिन मैं चाहूंगा
उन एडेप्टर वर्गों का भी परीक्षण करें। और तभी मुझे पता चलता है: वहाँ नहीं है
आईएचटीपी क्लाइंट। शायद तुम सही हो, इसकी जरूरत नहीं है। शायद आपको लगता है कि यह है
अमूर्तता का गलत स्तर। लेकिन यह वास्तव में सुविधाजनक नहीं होगा
इसे सभी परियोजनाओं में एक और वर्ग में लपेटना है। मैं बस नहीं देखता
इस तरह के एक महत्वपूर्ण वर्ग के लिए अलग इंटरफ़ेस न होने का कोई कारण।

लासे शॉउ
संस्थापक और मुख्य कार्यकारी अधिकारी

http://mouseflow.com
[email protected]

https://www.facebook.com/mouseflowdotcom/
https://twitter.com/mouseflow
https://www.linkedin.com/company/mouseflow

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

12 नवंबर 2016 को 14:57 बजे, जोसेफ मुसर नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1624#issuecomment -260123552, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/ACnGPp3fSriEJCAjXeAqMZbBcTWcRm9Rks5q9cXlgaJpZM4EPBHy
.

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

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

कृपया ठीक करें!

बस इस पर ठोकर खाई तो मेरे 2c को अंदर फेंक दिया ...

मुझे लगता है कि HttpClient का मजाक उड़ाना मूर्खता है।

यहां तक ​​​​कि केवल एक SendAsync नकल करने के लिए है, _so_ HttpResponseMessage , HttpResponseHeaders , HttpContentHeaders , आदि के लिए कई बारीकियां हैं, आपके मॉक जा रहे हैं जल्दी गड़बड़ हो जाते हैं और शायद गलत व्यवहार भी कर रहे हैं।

मैं? मैं OwinHttpMessageHandler का उपयोग करता हूं

1. किसी सेवा के बाहर से HTTP स्वीकृति परीक्षण करें।
2. _Dummy_ HTTP सेवाओं को उन घटकों में इंजेक्ट करें जो उक्त सेवाओं के लिए आउटबाउंड HTTP अनुरोध करना चाहते हैं। यही है, मेरे घटक में HttpMessageHandler के लिए वैकल्पिक सीटीआर पैरामीटर है।

मुझे यकीन है कि एक एमवीसी 6 हैंडलर है जो समान करता है ....

_जीवन ठीक है।_

@damianh : डॉटनेट कोर का उपयोग करने वाले लोगों को एचटीपी क्लाइंट जैसी कक्षा का परीक्षण करने के लिए ओविन के साथ कुछ भी करने की ज़रूरत क्यों है? यह किसी विशेष उपयोग के मामले (ओविन पर होस्ट किए गए एस्पकोर) के लिए बहुत मायने रखता है लेकिन यह सामान्य नहीं लगता है।

यह वास्तव में "मैं एकीकरण परीक्षण कैसे करूं" :) के साथ "यूनिट टेस्ट एचटीपी क्लाइंट के लिए सबसे सामान्य तरीका क्या है जो उपयोगकर्ता अपेक्षाओं के अनुरूप है" की चिंता को स्वीकार कर रहा है।

ओह _testing_ HttpClient... ने सोचा कि विषय उन चीजों का परीक्षण कर रहा था जिनमें a
एचटीपी क्लाइंट पर निर्भरता। मुझे बुरा मत मानना। :)

5 दिसंबर 2016 को शाम 7:56 बजे, " brphhelps " [email protected] ने लिखा:

@damianh https://github.com/damianh : लोगों को डॉटनेट कोर का उपयोग क्यों करना चाहिए?
HttpClient जैसी कक्षा का परीक्षण करने के लिए ओविन के साथ कुछ भी करने की ज़रूरत है? संभवत: यह
किसी विशेष उपयोग के मामले के लिए बहुत कुछ समझ में आता है (ओविन पर होस्ट किया गया एस्पकोर) लेकिन
यह सामान्य नहीं लगता है।

ऐसा लगता है कि यह वास्तव में "सबसे सामान्य क्या है" की चिंता का सामना कर रहा है
यूनिट टेस्ट एचटीपी क्लाइंट का तरीका जो उपयोगकर्ता अपेक्षाओं के अनुरूप भी है"
"मैं एकीकरण परीक्षण कैसे करूं" के साथ :)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1624#issuecomment-264942511 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AADgXJxunxBgFGLozOsisCoPqjMoch48ks5rFF5vgaJpZM4EPBHy
.

@damianh - यह ऐसी चीजें हैं जिन पर निर्भरता है, लेकिन आपके समाधान में चित्र में कई अन्य निर्भरताएं भी शामिल हैं। मैं एक क्लास लाइब्रेरी की कल्पना कर रहा हूं जो एचटीपी क्लाइंट इंस्टेंस (या एक DI'ed one) में उत्तीर्ण होने के लिए होता है - ओविन तस्वीर में कहां आता है?

यह ओविन नहीं है जो दिलचस्प बात है जिसे मैं दिखाने की कोशिश कर रहा था (जो
नेट कोर/नेटस्टैंडर्ड पर भी काम करेगा) इसलिए कृपया उस पर ध्यान न दें।

दिलचस्प बात यह है कि HttpMessageHandler एक इन-प्रोसेस बनाता है
डमी HTTP एंडपॉइंट्स के खिलाफ इन-मेमोरी HTTP अनुरोध।

Aspnet Core का TestServer, जैसा कि इससे पहले कटाना ने किया था, वही काम करता है
रास्ता।

तो परीक्षण के तहत आपकी कक्षा में एक HttpClient DI'd है जहां _it_ में एक है
HttpMessageHandler ने इसमें सीधे इंजेक्शन लगाया। परीक्षण योग्य और
दृढ़ सतह है।

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

5 दिसंबर 2016 को रात 8:15 बजे, " brphhelps " [email protected] ने लिखा:

@damianh https://github.com/damianh - यह ऐसी चीजें हैं जिनमें a . है
निर्भरता, लेकिन आपके समाधान में कई अन्य निर्भरताएं शामिल हैं
तस्वीर में भी। मैं एक क्लास लाइब्रेरी की कल्पना कर रहा हूं जो a . का उपयोग करता है
HttpClient उदाहरण (या एक DI'ed one) में पारित - ओविन कहां आता है
चित्र?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1624#issuecomment-264947538 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AADgXEESfQj9NnKLo8LucFLyajWtQXKBks5rFGK8gaJpZM4EPBHy
.

@damianh - पूरी तरह से समझें कि आप क्या कह रहे हैं दिलचस्प बात यह है - लेकिन लोगों को स्मार्ट मॉक के साथ डमी HTTP एंडपॉइंट्स की आवश्यकता नहीं है- जैसे @richardszalay की MockHttp लाइब्रेरी।

कम से कम यूनिट परीक्षण के लिए नहीं :)।

निर्भर करता है। विकल्प अच्छे हैं :)

5 दिसंबर 2016 को रात 8:39 बजे, " brphhelps " [email protected] ने लिखा:

@damianh https://github.com/damianh - पूरी तरह से समझें कि आप क्या हैं
दिलचस्प बात यह है कि - लेकिन लोगों को डमी HTTP की आवश्यकता नहीं है
स्मार्ट मॉक के साथ समापन बिंदु-- जैसे @richardszalay
https://github.com/richardszalay की MockHttp लाइब्रेरी।

कम से कम यूनिट परीक्षण के लिए नहीं :)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1624#issuecomment-264954210 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AADgXOl4UEDGYCVLpbvwhueaK52VtjH6ks5rFGhlgaJpZM4EPBHy
.

@damianh ने कहा:
विकल्प अच्छे हैं :)

हां - उस पर पूरी तरह सहमत हो सकते हैं 👍 कौन सा, आईएमओ .. हमारे पास अभी नहीं है 😢 **

मैं पूरी तरह से आपके एचएमएच को बनाने और इंजेक्शन लगाने के औचित्य को समझता हूं। मैं अभी यही कर रहा हूं। _दुर्भाग्य से_, मुझे एक दूसरा सीटीआर बनाना होगा (या एक वैकल्पिक सीटीआर परम प्रदान करना होगा) _इकाई परीक्षण चिंताओं के लिए_। बस उस वाक्य के बारे में फिर से सोचें -> मैं एक पूरी तरह से संभव उपयोगकर्ता विकल्प बना रहा हूं ... जो वास्तव में केवल एक इकाई परीक्षण को _do stuff_ में सक्षम करने के लिए है। मेरी कक्षा का अंतिम-उपयोगकर्ता/उपभोक्ता कभी भी _really_ उस ctor विकल्प का उपयोग नहीं करेगा ... जिससे मुझे गंध आती है।

विकल्पों के मुद्दे पर वापस -> अभी मुझे नहीं लगता कि हमारे पास एक है। हम HttpClient के इंटर्नल के बारे में _है_ से _सीखते हैं। सचमुच बोनट खोलें और हुड के नीचे देखें। (मैं भाग्यशाली था कि मुझे सर फाउलर द विस्मयकारी ™ से टीएल; डीआर मिला, जिसने मेरे शोध के समय को कम कर दिया)।

तो - नो-इंटरफ़ेस होने के बारे में अपनी बात के साथ, क्या आप कृपया कुछ उदाहरण प्रदान कर सकते हैं कि इंटरफ़ेस कब खराब होगा, कृपया? आदि। याद रखें -> मैं हमेशा छोटे/सरल से मध्यम उदाहरणों के लिए एक इंटरफ़ेस को _option_ के रूप में प्रचारित करता रहा हूं ... सभी उदाहरणों में से 100% नहीं।

मैं आपको डेमियन को ट्रोल या हमला करने की कोशिश नहीं कर रहा हूं - बस समझने की कोशिश कर रहा हूं।

* निंजा संपादित करें: तकनीकी रूप से, हमारे पास वास्तव में विकल्प हैं -> हम कुछ भी नहीं कर सकते हैं / अपने स्वयं के रैपर / आदि बना सकते हैं। मेरा मतलब था: कई विकल्प नहीं जो चीजों को सरल बनाते हैं, *आउट-ऑफ-द-बॉक्स ।

अरे @PureKrome , कोई चिंता नहीं सिर्फ अनुभव साझा करना।

'यूनिट टेस्ट' शब्द का प्रयोग कई बार किया गया है और आइए इस बारे में एक मिनट के लिए सोचें। तो हम एक ही पृष्ठ पर हैं, मुझे लगता है कि हमारे पास FooClass है जिसमें HttpClient (या HMH ) पर सीटीआर निर्भरता है और हम _mock_ HttpClient करना चाहते हैं

हम वास्तव में यहां क्या कह रहे हैं " FooClass किसी भी विधि, किसी भी सामग्री प्रकार, किसी भी स्थानांतरण-एन्कोडिंग, किसी भी सामग्री-एन्कोडिंग, _any का उपयोग करके किसी भी यूआरएल (प्रोटोकॉल/होस्ट/संसाधन) का उपयोग करके HTTP अनुरोध कर सकता है। हेडर_ का अनुरोध करें, और किसी भी प्रतिक्रिया सामग्री-प्रकार, किसी भी स्थिति कोड, कुकीज़, रीडायरेक्ट, ट्रांसफर एन्कोडिंग, कैशे कंट्रोल हेडर, आदि के साथ-साथ नेटवर्क टाइमआउट, कार्य रद्द अपवाद आदि को संभाल सकता है।

HttpClient एक ईश्वर वस्तु की तरह है; आप इसके साथ बहुत कुछ कर सकते हैं। HTTP भी एक दूरस्थ सेवा कॉल है जो आपकी प्रक्रिया से परे पहुंचती है।

क्या यह वास्तव में इकाई परीक्षण है? अब ईमानदार रहो :)

** निंजा भी संपादित करें: यदि आप FooClass इकाई को परीक्षण योग्य बनाना चाहते हैं जहां वह सर्वर से कुछ जेसन प्राप्त करना चाहता है, तो इसकी Func<CancellationToken, Task<JObject>> या इसी तरह की सीटीआर निर्भरता होगी।

क्या आप कृपया कुछ उदाहरण प्रदान कर सकते हैं कि इंटरफ़ेस कब खराब होगा, कृपया

ऐसा नहीं कहा! मैंने कहा कि IHttpClient उपयोगी नहीं होगा क्योंकि ए) इसे वैकल्पिक ठोस कार्यान्वयन के साथ प्रतिस्थापित नहीं किया जाएगा और बी) भगवान वस्तु चिंता जैसा कि उल्लेख किया गया है।

एक और उदाहरण? IAssembly ।

@damianh - "गॉड क्लास" की स्थिति कॉल करने वालों के लिए चिंता का विषय नहीं है। यह सुनिश्चित करने के लिए कॉल करने वालों की ज़िम्मेदारी नहीं है कि HttpClient एक ईश्वर वर्ग नहीं है। वे जानते हैं कि यह वह वस्तु है जिसका उपयोग वे HTTP कॉल करने के लिए करते हैं :)।

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

व्याकरण और स्पष्टता के लिए कुछ संपादन :D

@damianh से पूरी तरह सहमत हैं कि HttpClient कुछ uber God Class की तरह है।

मैं यह भी नहीं देखता कि मुझे सभी आंतरिक के बारे में फिर से जानने की आवश्यकता क्यों है क्योंकि इसमें _बहुत सारे purmutations_ हो सकते हैं जो अंदर जाता है, जो बाहर आता है।

उदाहरण के लिए: मैं कुछ एपीआई से स्टॉक प्राप्त करना चाहता हूं। https://api.stock-r-us.com/aapl । परिणाम कुछ JSON पेलोड है।

इसलिए, उस समापन बिंदु को कॉल करने का प्रयास करते समय मैं जिन चीजों को खराब कर सकता हूं:

• गलत समापन बिंदु यूआरएल?
• गलत योजना?
• विशेष शीर्षलेख गुम हैं?
• गलत हेडर
• गलत अनुरोध पेलोड (शायद यह किसी निकाय के साथ एक पोस्ट है?)
• नेटवर्क त्रुटि/समयबाह्य/आदि
  ...

इसलिए मैं समझता हूं कि अगर मैं इन चीजों के लिए परीक्षण करना चाहता हूं, तो एचएमएच ऐसा करने का एक शानदार तरीका है क्योंकि यह सिर्फ _real_ एचएमएच को हाईजैक करता है और जो मैंने कहा है, उसे वापस करने के लिए प्रतिस्थापित करता है।

लेकिन - क्या होगा अगर मैं चाहता हूं कि (अपने जोखिम पर) इन सभी चीजों को अनदेखा करें और बस कहें:
_कल्पना कीजिए कि मैं कॉल करना चाहता हूं और एंडपॉइंट करना चाहता हूं, सब कुछ ठीक है और मुझे मेरा अच्छा जेसन पेलोड परिणाम मिलता है।_
क्या मुझे अभी भी इन सभी चीजों के बारे में सीखना और चिंता करना चाहिए, इतना आसान कुछ करने के लिए?

या ... क्या यह सोचने का एक खराब तरीका है। हमें ऐसा कभी नहीं सोचना चाहिए क्योंकि यह बहुत हैकी है? बेहद सस्ता? त्रुटियों के लिए बहुत प्रवण?

ज्यादातर समय मैं सिर्फ एक समापन बिंदु कहता हूं। मैं हेडर या कैश-कंट्रोल या नेटवर्क त्रुटियों जैसी चीजों के बारे में नहीं सोचता। मैं आमतौर पर केवल VERB + URL (और पेलोड, यदि आवश्यक हो) और फिर परिणाम के बारे में सोचता हूं। मुझे इसके आसपास कैच-ऑल-द-थिंग्स को संभालने में त्रुटि है: टीएम: और फिर हार मान लें क्योंकि कुछ बुरा हुआ :(

तो मैं या तो समस्या को गलत देख रहा हूं (यानी मैं अभी भी अपनी n00b स्थिति को हिला नहीं सकता) -या- यह ईश्वर वर्ग हमें इकाई परीक्षण दुःख का ढेर बना रहा है।

HTTP भी एक दूरस्थ सेवा कॉल है जो आपकी प्रक्रिया से परे पहुंचती है।
क्या यह वास्तव में इकाई परीक्षण है? अब ईमानदार रहो :)

मेरे लिए, HttpClient एक _निर्भर सेवा_ है। मुझे परवाह नहीं है _What_ सेवा वास्तव में करती है, मैं इसे _something के रूप में वर्गीकृत करता हूं जो कुछ सामान करता है जो मेरे कोडबेस के बाहर है। इसलिए, मैं नहीं चाहता कि यह बाहरी शक्ति के साथ सामान करे, इसलिए मैं इसे नियंत्रित करना चाहता हूं, इसे हाईजैक करना और उन सेवा-कॉल के परिणामों को निर्धारित करना चाहता हूं। मैं अभी भी काम की _my_ इकाई का परीक्षण करने की कोशिश कर रहा हूं। तर्क का मेरा छोटा सा टुकड़ा। निश्चित रूप से यह अन्य सामानों पर निर्भर हो सकता है। यह अभी भी एक इकाई परीक्षण है अगर मैं पूरे ब्रह्मांड को नियंत्रित कर सकता हूं तो तर्क का यह टुकड़ा _and_ के भीतर मौजूद है, मेरे पास अन्य सेवाओं पर भरोसा/एकीकृत नहीं है।

** एक और संपादन: या हो सकता है - अगर एचटीपी क्लाइंट वास्तव में एक ईश्वर वस्तु है, तो शायद बातचीत इसे कुछ कम करने के आसपास होनी चाहिए ... बेहतर? या हो सकता है, यह बिल्कुल भी ईश्वरीय वस्तु नहीं है? (बस बहस को खोलने की कोशिश कर रहा है) ..

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

मुझे यकीन नहीं है कि आप यहां क्या कहना चाह रहे हैं:

"मुझे दूसरा ctor पसंद नहीं है जो HttpMessageHandler स्वीकार करता है" ... तो क्या आपके परीक्षण इसे HttpClient में लपेटते हैं

"मैं एचटीपी क्लाइंट पर अपनी निर्भरता को बदलने के बिना यूनिट परीक्षण करना चाहता हूं" ... कठिन?

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

मैं इसके बारे में MockHttp के संदर्भ में नहीं सोच रहा हूं, लेकिन सामान्य रूप से परीक्षण/मजाक कर रहा हूं।
उलटा निर्भरता .NET में इकाई परीक्षण के लिए एक मूलभूत आवश्यकता है, और इसमें आमतौर पर सीटीआर-इंजेक्शन शामिल होता है। मैं स्पष्ट नहीं हूं कि प्रस्तावित विकल्प क्या होगा।

निश्चित रूप से यदि एचटीपी क्लाइंट ने आईएचटीपी क्लाइंट लागू किया है, तो अभी भी एक कन्स्ट्रक्टर होगा जिसने इसे स्वीकार कर लिया है ...

निश्चित रूप से यदि एचटीपी क्लाइंट ने आईएचटीपी क्लाइंट लागू किया है, तो अभी भी एक कन्स्ट्रक्टर होगा जिसने इसे स्वीकार कर लिया है ...

माना। मैं अपनी सोच में "धाराओं को पार कर रहा था" क्योंकि मैं सचमुच अभी-अभी उठा था और अपने मस्तिष्क में अपनी एकल कोशिका को जीवित करने के लिए संघर्ष कर रहा था।

कृपया मेरी 'ctor' टिप्पणी को अनदेखा करें और चर्चा जारी रखें, अगर कोई पहले से ही बोरियत में नहीं छोड़ा है

क्या हम इस प्रश्न पर एक कदम पीछे हट सकते हैं यदि एक निर्भरता के रूप में HttpClient का उपयोग वास्तव में _can_ इकाई परीक्षण की ओर ले जाता है।

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

अब वर्तमान में मुझे HttpClient को लागू करने के तरीके की परवाह करनी है क्योंकि मुझे परीक्षण के तहत मेरे सिस्टम के लिए मेरी इंजेक्शन निर्भरता ( HttpClient ) के लिए एक निर्भरता ( HttpMessageHandler ) निर्दिष्ट करनी है। अपनी प्रत्यक्ष निर्भरता का मजाक उड़ाने के बजाय, मुझे एक नकली जंजीर निर्भरता के साथ इसका एक ठोस कार्यान्वयन करना होगा।

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

आप कई अलग-अलग टिप्पणियों में मौजूद विषय को देख सकते हैं:

"मेरे लिए, एचटीपी क्लाइंट एक आश्रित सेवा है। मुझे परवाह नहीं है कि सेवा वास्तव में क्या करती है, मैं इसे कुछ ऐसी चीज के रूप में वर्गीकृत करता हूं जो मेरे कोडबेस के बाहर कुछ सामान करता है।" - प्योरक्रोम

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

"मैं एक ही बात पूछने वाला था क्योंकि यह एक ग्राहक के रूप में देखकर एक आदर्श स्तर का अमूर्तता है।" -- दासजेस्टीरो

"HttpMessageHandler प्रभावी रूप से "कार्यान्वयन" है। आप आम तौर पर एक HttpClient बनाते हैं, हैंडलर को कंस्ट्रक्टर में पास करते हैं, और फिर आपकी सेवा परत HttpClient पर निर्भर होती है।" -- रिचर्ड्सज़ाले

"लेकिन मुख्य मुद्दा बना रहेगा - आपको एक नकली हैंडलर को परिभाषित करने और इसे HttpClient ऑब्जेक्ट के नीचे डालने की आवश्यकता होगी।" -- सिद्धार्थ नबरी

"एचटीपी क्लाइंट के पास यूनिट टेस्टेबिलिटी के लिए बहुत सारे विकल्प हैं। इसे सील नहीं किया गया है और इसके अधिकांश सदस्य वर्चुअल हैं। इसमें बेस क्लास है जिसका उपयोग एब्स्ट्रैक्शन को सरल बनाने के लिए किया जा सकता है और साथ ही HttpMessageHandler में सावधानीपूर्वक डिज़ाइन किए गए एक्सटेंशन पॉइंट" - ericstj

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

"सम्मान के साथ, यदि विकल्प को अपना खुद का फेक मैसेज हैंडलर लिखना है, जो कोड के माध्यम से खोदे बिना स्पष्ट नहीं है, तो यह एक बहुत ही उच्च बाधा है जो बहुत सारे डेवलपर्स के लिए बेहद निराशाजनक होने वाला है।" -- ctolkien

क्या यह वास्तव में इकाई परीक्षण है? अब ईमानदार रहो :)

मुझे नही पता। परीक्षण कैसा दिखता है?

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

HttpClient अब तक की सबसे खराब निर्भरता है। यह शाब्दिक रूप से कहता है कि
आश्रित "इंटरनेट को कॉल" कर सकता है। निश्चित रूप से आप आगे TCP का मज़ाक उड़ा रहे होंगे। हेह

7 दिसंबर 2016 को सुबह 5:34 बजे, "जेरेमी स्टैफोर्ड" नोटिफिकेशन @github.com ने लिखा:

क्या यह वास्तव में इकाई परीक्षण है? अब ईमानदार रहो :)

मुझे नही पता। परीक्षण कैसा दिखता है?

मुझे लगता है कि बयान थोड़ा स्ट्रॉमैन है। बात मजाक करने की है
निर्भरता जो http क्लाइंट है। हम केवल यह सुनिश्चित करेंगे कि
इंटरफ़ेस पर अपेक्षित विधियों को दाईं ओर बुलाया जा रहा था
शर्तेँ। हमें हल्की निर्भरता चुननी चाहिए थी या नहीं ऐसा लगता है
एक पूरी तरह से अलग चर्चा होने के लिए।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/1624#issuecomment-265353526 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AADgXPL39vnUbWrUuUBtfmbjhk5IBkxHks5rFjdqgaJpZM4EPBHy
.

यह मूल रूप से यूनिट परीक्षण 101 का पालन नहीं कर रहा है - आपके परीक्षणों से असंबंधित निर्भरता कोड प्राप्त करना =)।

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

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

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

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

अब मैं देखता हूं कि हैंडलर वह हिस्सा है जो कोड के लिए मायने रखता है, इसलिए मैं इसे आगे बढ़ने के लिए डिजाइन कर रहा हूं।

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

ठीक है, मैं बिक गया हूँ। मैं अब मॉकिंग के लिए HttpClient पर इंटरफ़ेस नहीं चाहता।

लंबे समय तक संघर्ष करने के बाद मैंने अपना IHttpHandler इंटरफ़ेस बनाया और अपने उपयोग के मामले में सब कुछ लागू किया। मेरे ठोस कोड को पढ़ने में आसान बनाता है और कुछ अजीब गधे सामान के बिना परीक्षणों का मज़ाक उड़ाया जा सकता है।

आज इस पर आया: http://www.davesquared.net/2011/04/dont-mock-types-you-dont-own.html

जैसे ही आपको प्रत्येक अनुरोध पर अलग-अलग HTTP शीर्षलेख भेजने की आवश्यकता होती है (ठीक से डिज़ाइन की गई रीस्टफुल वेब सेवाओं के साथ संचार करते समय क्या महत्वपूर्ण है) एचटीपी क्लाइंट के किसी भी वास्तव में एप्लिकेशन को साझा करना असंभव है। वर्तमान में HttpRequestHeaders DefaultRequestHeaders उदाहरण के लिए बाध्य है और इसे प्रभावी ढंग से स्टेटफुल बनाने के लिए कॉल करने के लिए नहीं है। इसके बजाय {Method}Async() को इसे स्वीकार करना चाहिए जो HttpClient को स्टेटलेस और वास्तव में पुन: प्रयोज्य बना देगा।

@abatishchev लेकिन आप प्रत्येक HttpRequestMessage पर शीर्षलेख निर्दिष्ट कर सकते हैं।

@richardszalay मैं यह नहीं कहता कि यह पूरी तरह से असंभव है, मैं कहता हूं कि HttpClient को इस उद्देश्य के लिए अच्छी तरह से डिज़ाइन नहीं किया गया था। {Method}Async() HttpRequestMethod नहीं करता है, केवल SendAsync() करता है। लेकिन फिर बाकी का उद्देश्य क्या है?

लेकिन फिर बाकी का उद्देश्य क्या है?

99% जरूरतों को पूरा करना।

क्या इसका मतलब है कि हेडर सेट करना 1% उपयोग के मामले हैं? मुझे शक है।

किसी भी तरह से यह कोई मुद्दा नहीं होगा यदि उन तरीकों में HttpResponseMessage को स्वीकार करने वाला अधिभार था।

@abatishchev मुझे इसमें संदेह नहीं है, लेकिन किसी भी तरह से, अगर मैं खुद को आपके परिदृश्य में पाता हूं तो मैं विस्तार विधियां लिखूंगा।

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

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

@dasjestyr क्या आपने HttpMessageHandler या HttpRequestMessage के इंटरफेस के बजाय HttpClient (जो इसके लिए एक रैपर बनाने जैसा है) के लिए एक इंटरफ़ेस बनाने का प्रयास किया था ..

/ मुझे उत्सुक।

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

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

मुझे लगता है कि यह अभी भी हैंडलर को इंटरफेस करने के लिए उपयोगी हो सकता है, लेकिन इसे वहां रुकना होगा। आपका मॉकिंग फ्रेमवर्क तब HttpResponseMessage के पूर्व-निर्धारित उदाहरणों को वापस करने के लिए सेटअप किया जा सकता है।

दिलचस्प। मैंने पाया है (व्यक्तिगत पूर्वाग्रह?) मेरी सहायक लाइब्रेरी एक (नकली) ठोस संदेश हैंडलर .. बनाम .. उस निम्न स्तर पर कुछ इंटरफ़ेस सामग्री का उपयोग करते समय बहुत अच्छा काम करती है।

मैं अभी भी उस पुस्तकालय को लिखना या उसका उपयोग नहीं करना पसंद करूंगा, हालांकि :)

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

जब अधिकांश कोडबेस का परीक्षण मॉकिंग इंटरफेस का उपयोग करके किया जाता है, तो यह अधिक सुविधाजनक और सुसंगत होता है जब बाकी कोडबेस का परीक्षण उसी तरह किया जाता है। तो मैं एक इंटरफ़ेस IHttpClient देखना चाहता हूं। जैसे ADL SDK से IFileSystemOperaions या ADF प्रबंधन SDK से IDataFactoryManagementClient, आदि।

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

इसके अलावा, आपके आश्रित वर्गों को एचटीपी क्लाइंट की परवाह नहीं करनी चाहिए, केवल वह डेटा जो इसके द्वारा लौटाया जाता है - जो हैंडलर से आता है। इसके बारे में इस तरह से सोचें: क्या आप कभी भी HttpClient कार्यान्वयन को किसी और चीज़ से बदलने जा रहे हैं? संभव है... लेकिन संभावना नहीं है। आपको क्लाइंट के काम करने के तरीके को बदलने की जरूरत नहीं है, तो इसे अमूर्त करने की जहमत क्यों उठाएं? संदेश हैंडलर चर है। आप बदलना चाहते हैं कि प्रतिक्रियाओं को कैसे संभाला जाता है, लेकिन ग्राहक क्या नहीं करता है। यहां तक ​​​​कि वेबएपीआई में पाइपलाइन हैंडलर पर केंद्रित है (देखें: प्रतिनिधि हैंडलर)। जितना अधिक मैं इसे कहता हूं, उतना ही मुझे लगता है कि नेट को क्लाइंट को स्थिर बनाना चाहिए और इसे आपके लिए प्रबंधित करना चाहिए ... लेकिन मेरा मतलब है ... जो भी हो।

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

हे @dasjestyr - मुझे भी लगता है कि आप मेरी चर्चा के एक प्रमुख बिंदु से चूक गए होंगे।

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

मुझे उम्मीद है कि इस महाकाव्य धागे का मुख्य सार यह है कि .. किसी एप्लिकेशन में एचटीपी क्लाइंट का उपयोग करते समय, यह इसके साथ परीक्षण करने के लिए एक पिटा है।

"जाओ HttpClient की पाइपलाइन सीखो, जो आपको HttpMessageHandler, आदि तक ले जाएगा" की स्थिति एक खराब स्थिति है। हमें कई अन्य पुस्तकालयों आदि के लिए ऐसा करने की आवश्यकता नहीं है।

तो मैं उम्मीद कर रहा था कि इस पिटा को कम करने के लिए कुछ किया जा सकता है।

हां, पिटा एक राय है - मैं इसे पूरी तरह से स्वीकार करूंगा। कुछ लोग नहीं सोचते कि यह एक पिटा है, आदि।

असली समस्या यह है कि लोग एचटीपी क्लाइंट को देखते हैं। जब भी आप इंटरनेट पर कॉल करने के बारे में सोचते हैं तो यह कुछ यादृच्छिक वर्ग नहीं है जिसे नया किया जाना चाहिए।

माना! लेकिन कुछ समय पहले तक, यह अच्छी तरह से ज्ञात नहीं था - जिसके कारण दस्तावेज़ीकरण या शिक्षण या कुछ और की कमी हो सकती है।

साथ ही, आपके आश्रित वर्गों को HttpClient की परवाह नहीं करनी चाहिए, केवल वह डेटा जो इसके द्वारा लौटाया जाता है

हाँ - सहमत।

जो हैंडलर से आता है।

एक क्या? हुह? ओह - अब आप मुझसे हुड खोलने और प्लंबिंग के बारे में जानने के लिए कह रहे हैं? ... बार-बार ऊपर का संदर्भ लें।

इसके बारे में इस तरह से सोचें: क्या आप कभी भी HttpClient कार्यान्वयन को किसी और चीज़ से बदलने जा रहे हैं?

नहीं।

.. आदि ..

अब, मेरा मतलब ट्रोल आदि से नहीं है। इसलिए कृपया यह न सोचें कि मैं हमेशा एक ही सामान का बार-बार जवाब देकर और दोहराकर एक झटका बनने की कोशिश कर रहा हूं।

मैं सदियों से अपनी सहायक पुस्तकालय का उपयोग कर रहा हूं जो एक कस्टम संदेश हैंडलर का उपयोग करने का एक शानदार तरीका है। महान! यह काम करता है और बढ़िया काम करता है। मुझे लगता है कि यह _all_ थोड़ा अच्छा हो सकता है ... और यही मैं उम्मीद कर रहा हूं कि यह धागा वास्तव में घर पर हिट हो।

संपादित करें: स्वरूपण।

(मैंने अभी-अभी इस अंक के शीर्षक में व्याकरण की त्रुटि देखी है और अब मैं इसे नहीं देख सकता)

और वह मेरा _real_ लंबा खेल रहा है :)

क्यूईडी

(वास्तव में - इतना शर्मनाक 😊)

संपादित करें: मेरा हिस्सा इसे संपादित नहीं करना चाहता .. पुरानी यादों के लिए ....

(मैंने अभी-अभी इस अंक के शीर्षक में व्याकरण की त्रुटि देखी है और अब मैं इसे नहीं देख सकता)

मैं जानती हूँ! वैसा ही!

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

क्या?

क्या आपने HttpMessageHandler को भी देखा है? यह एक अमूर्त वर्ग है जो सचमुच एक एकल विधि है जो एक HttpRequestMessage लेता है और एक HttpResponseMessage देता है - सभी निम्न स्तर के परिवहन जंक से अलग व्यवहार को रोकने के लिए बनाया गया है जो कि आप एक इकाई परीक्षण में चाहते हैं। इसे नकली बनाने के लिए, बस इसे लागू करें। जो संदेश जाता है वह वह है जिसे आपने HttpClient भेजा है, और जो प्रतिक्रिया आती है वह आप पर निर्भर है। उदाहरण के लिए, अगर मैं जानना चाहता हूं कि मेरा कोड एक जेसन बॉडी से सही तरीके से निपट रहा है, तो बस प्रतिक्रिया को एक जेसन बॉडी लौटाएं जो आप उम्मीद करते हैं। यदि आप यह देखना चाहते हैं कि क्या यह 404 को सही ढंग से संभाल रहा है, तो क्या यह 404 लौटाता है। यह उससे अधिक बुनियादी नहीं है। हैंडलर का उपयोग करने के लिए, बस इसे HttpClient के लिए एक ctor तर्क के रूप में भेजें। आपको किसी भी तार को बाहर निकालने या किसी भी चीज़ की आंतरिक कार्यप्रणाली सीखने की आवश्यकता नहीं है।

मुझे उम्मीद है कि इस महाकाव्य धागे का मुख्य सार यह है कि .. किसी एप्लिकेशन में एचटीपी क्लाइंट का उपयोग करते समय, यह इसके साथ परीक्षण करने के लिए एक पिटा है।

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

मुझे लगता है कि विंडोज़ नेमस्पेस में HttpClient ने वास्तव में हैंडलर की अवधारणा को फ़िल्टर में अलग कर दिया था, लेकिन यह वही काम करता है। मुझे लगता है कि उस कार्यान्वयन में हैंडलर/फ़िल्टर वास्तव में इंटरफेस किया गया है, हालांकि मैं पहले जो सुझाव दे रहा था वह थोडा है।

क्या?
क्या आपने HttpMessageHandler को भी देखा है?

प्रारंभ में नहीं, इस वजह से:

var payloadData = await _httpClient.GetStringAsync("https://......");

अर्थ, HttpClient पर उजागर तरीके वास्तव में अच्छे हैं और चीजों को _really_ आसान बनाते हैं :) याय! तेज, सरल, काम करता है, जीतो!

ठीक है - तो अब इसे एक परीक्षण में उपयोग करते हैं ... और अब हमें यह जानने में समय बिताने की आवश्यकता है कि नीचे क्या होता है .. जो हमें HttpMessageHandler आदि के बारे में सीखने की ओर ले जाता है।

फिर से मैं यह कहता रहता हूं => HttpClient (यानी HMH , आदि) की नलसाजी के बारे में यह अतिरिक्त सीख एक पिटा है। एक बार जब आपने वह सीख लिया _ .. हां, फिर मुझे पता है कि इसका उपयोग कैसे करना है आदि ... भले ही मैं इसका उपयोग करना पसंद नहीं करता, लेकिन तीसरे पक्ष के समापन बिंदुओं पर दूरस्थ कॉल का मजाक उड़ाने के लिए इसकी आवश्यकता होती है। ज़रूर, यह माना जाता है। हम केवल असहमत होने के लिए सहमत हो सकते हैं। तो कृपया - मुझे HMH के बारे में पता है और इसका उपयोग कैसे करना है।

और कई लोगों ने जो बताया है उसका मुख्य सार यह है कि आप इसे गलत कर रहे हैं

हाँ - लोग मुझसे असहमत हैं। कोई जाँच नहीं। साथ ही - लोग भी मुझसे सहमत हैं। फिर से, कोई जांच नहीं।

और _demanding_ कि HttpClient को परीक्षण उद्देश्यों के लिए इंटरफेस किया जाना चाहिए, मूल समस्या को संबोधित करने के बजाय बग की क्षतिपूर्ति करने के लिए सुविधाओं को बनाने के समान है, इस मामले में, कि आप गलत स्तर पर काम कर रहे हैं।

ठीक है - मैं यहां आपसे सम्मानपूर्वक असहमत हूं (जो ठीक है)। फिर से, अलग राय।

लेकिन सरसली। यह सिलसिला इतने लंबे समय से चला आ रहा है। मैं वास्तव में अब तक आगे बढ़ चुका हूं। मैंने कहा मेरी बात, कुछ लोग कहते हैं हाँ! कुछ ने कहा नहीं! कुछ भी नहीं बदला है और मैंने बस ... यथास्थिति को स्वीकार कर लिया है और सब कुछ के साथ लुढ़क गया हूं।

मुझे खेद है कि आपने मेरे विचार की ट्रेन को स्वीकार नहीं किया। मैं एक बुरा व्यक्ति नहीं हूं और कठोर या मतलबी नहीं लगने की कोशिश करता हूं। यह सिर्फ मैं व्यक्त कर रहा था कि विकास के दौरान मैंने कैसा महसूस किया और मुझे विश्वास है कि दूसरों ने भी कैसा महसूस किया। बस इतना ही।

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

स्वगत कथन के रूप में:

प्रारंभ में नहीं, इस वजह से:

वर पेलोडडेटा = प्रतीक्षा करें _httpClient.GetStringAsync("https://......");

अर्थ, एचटीपी क्लाइंट पर उजागर विधियां वास्तव में अच्छी हैं और चीजों को वास्तव में आसान बनाती हैं :) याय! तेज़, >सरल, काम करता है, जीतें!

मेरा तर्क है कि SOLID के संदर्भ में, यह इंटरफ़ेस वैसे भी अनुपयुक्त है। आईएमओ क्लाइंट, अनुरोध, प्रतिक्रिया 3 अलग-अलग जिम्मेदारियां हैं। मैं क्लाइंट पर सुविधा के तरीकों की सराहना कर सकता हूं, लेकिन यह क्लाइंट के साथ अनुरोधों और प्रतिक्रियाओं को जोड़कर तंग युग्मन को बढ़ावा देता है, लेकिन यह व्यक्तिगत प्राथमिकता है। मेरे पास HttpResponseMessage के कुछ एक्सटेंशन हैं जो एक ही चीज़ को पूरा करते हैं लेकिन प्रतिक्रिया संदेश के साथ प्रतिक्रिया पढ़ने की ज़िम्मेदारी रखते हैं। मेरे अनुभव में, बड़ी परियोजनाओं के साथ, "सरल" कभी भी "सरल" नहीं होता है और लगभग हमेशा बीबीओएम में समाप्त होता है। हालांकि, यह एक पूरी तरह से अलग चर्चा है :)

अब जब हमारे पास विशेष रूप से डिजाइन चर्चा के लिए एक नया रेपो है, तो कृपया https://github.com/dotnet/designs/issues/9 में चर्चा जारी रखें या https://github.com/dotnet/designs में एक नया मुद्दा खोलें।

धन्यवाद।

शायद इसे केवल परीक्षण उद्देश्य के लिए समाधान के नीचे माना जा सकता है:

पब्लिक क्लास जियोलोकेशन सर्विसफॉरटेस्ट: जियोलोकेशन सर्विस, IGeoLocationService
{
सार्वजनिक GeoLocationServiceForTest (कुछ: कुछ, HttpClient httpClient): आधार (कुछ)
{
आधार._httpClient = httpClient;
}
}

मैं @richardszalay के MockHttp का उपयोग कर समाप्त हुआ।
धन्यवाद, रिचर्ड, आपने मेरा दिन बचाया!

ठीक है, मैं बिना इंटरफेस वाले HttpClient के साथ रह सकता हूं। लेकिन HttpMessageHandler विरासत में मिली कक्षा को लागू करने के लिए मजबूर होना क्योंकि SendAsync संरक्षित है बस बेकार है।

मैं NSubstitute का उपयोग करता हूं, और यह काम नहीं करता है:

var httpMessageHandler = 
    Substitute.For<HttpMessageHandler>(); // cannot be mocked, not virtual nor interfaced
httpMessageHandler.SendAsync(message, cancellationToken)
    .Return(whatever); // doesn't compile, it's protected
var httpClient = new HttpClient(httpMessageHandler)

वास्तव में निराशाजनक।