Dependencyinjection: अपूर्ण पंजीकरण के लिए संपत्ति इंजेक्शन विफल होना चाहिए

को निर्मित 13 मई 2016 · 9टिप्पणियाँ · स्रोत: aspnet/DependencyInjection

RC2 के लिए लाइटइन्जेक्ट तैयार होने की प्रक्रिया में, मैंने नवीनतम बिट्स के खिलाफ परीक्षण चलाए और पता चला कि मेरे पास एक असफल परीक्षण था (ClosedServicesPreferredOverOpenGenericServices)। यह परीक्षण पास हो जाता था और केवल एक चीज जो बदल गई थी वह थी पुराने संस्करण में एक स्ट्रिंग के बजाय जेनेरिक तर्क के रूप में अन्यक्लैस का उपयोग करना। मैं जल्दी ही पता चला है कि यह विफल हो गया क्योंकि कि AnotherClass एक निर्माता निर्भरता (IFakeService) कि कंटेनर के साथ पंजीकृत नहीं है है। मैं संपत्ति इंजेक्शन के लिए ढीली रणनीति को समझता हूं, लेकिन अगर संपत्ति निर्भरता दर्ज की गई है तो आईएमएचओ को विफल होना चाहिए और बदले में निर्भरता एक निर्भरता है जो पंजीकृत नहीं है / resolvable नहीं है। अन्यथा यह कुछ परिदृश्यों को जन्म दे सकता है जो डीबग करना बहुत कठिन हो सकता है।

मुझे स्पष्ट कीजिए कि एक दो परीक्षणों से मेरा क्या अभिप्राय है।

 public void ShouldHandleMissingPropertyDepenency()
{
    // Arrange 
    var collection = new ServiceCollection();
    collection.AddTransient(typeof(FakeService), typeof(FakeService));
    var provider = CreateServiceProvider(collection);

    // Act 
    var service = provider.GetService<FakeService>();

    // Assert
    Assert.IsType<FakeService>(service);
    Assert.Null(service.Value);                        
}

तथ्य यह है कि मूल्य शून्य है (एक और क्लस्टर) पूरी तरह से ठीक है क्योंकि यह सेवा संग्रह में कभी पंजीकृत नहीं था। अगला परीक्षण समस्या को प्रदर्शित करता है।

public void ShouldThrowExceptionForIncompletePropertyDependency()
{           
    // Arrange
    var collection = new ServiceCollection();
    collection.AddTransient(typeof(FakeService));
    collection.AddTransient(typeof(AnotherClass));
    var provider = CreateServiceProvider(collection);

    // THIS SHOULD FAIL 
    var service = provider.GetService<FakeService>();

}

यह परीक्षण विफल हो जाना चाहिए क्योंकि संपत्ति निर्भरता (एक और क्लेमास) पंजीकृत है, लेकिन वास्तव में रिज़ॉल्व करने योग्य नहीं है क्योंकि अन्य क्लैक्सेस के पास अपंजीकृत आवश्यक निर्माण निर्भरता है।

यदि यह (खतरनाक) व्यवहार डिजाइन द्वारा होता है, तो कम से कम परीक्षण होना चाहिए जो इस व्यवहार की पुष्टि करता है।

3 - Done bug

स्रोत

seesharper

सबसे उपयोगी टिप्पणी

लेकिन डिफ़ॉल्ट कार्यान्वयन का व्यवहार भी अनुबंध का हिस्सा है

@ शेयशर यहां पर हाजिर है: निर्मित कंटेनर एडॉप्टर के अनुबंध को परिभाषित करता है।

मुझे ऐसा लगता है कि Microsoft को वास्तव में कभी इस बात का एहसास नहीं हुआ, क्योंकि यदि वे ऐसा करेंगे, तो ऐसे और भी परीक्षण होंगे जो एडॉप्टर के व्यवहार को सत्यापित करते हैं। 41 परीक्षणों के साथ, वर्तमान में एक एडाप्टर का निर्माण करना काफी आसान है जो सभी परीक्षणों को हरा बनाता है, लेकिन यह वास्तविक दुनिया के उपयोग के साथ विफल हो जाएगा, क्योंकि यह अंतर्निहित कंटेनर द्वारा परिभाषित व्यवहार का सटीक सुपरसेट नहीं है।

और चीजों को बदतर बनाने के लिए, v1 के बाद बिल्ट-इन डीआई लाइब्रेरी में जोड़ा जाने वाला प्रत्येक फीचर एक ब्रेकिंग परिवर्तन होगा, क्योंकि - निर्मित लाइब्रेरी अनुबंध का हिस्सा है। हर जोड़ा फीचर हर मौजूदा एडॉप्टर को तोड़ देगा। तो वास्तव में, एडेप्टर का अस्तित्व यहां तक कि निर्मित कंटेनर के भीतर भी सुधार और नवीनता को रोकता है; हर परिवर्तन एक ब्रेकिंग परिवर्तन है। यह ठीक उसी तरह है जैसे @ploeh , @danielmarbach और खुद लोग Microsoft को उनके एडॉप्टर के बारे में आगाह कर रहे हैं।

dotnetjunkie 15 मई 2016

👍7

सभी 9 टिप्पणियाँ

मुझे लगता है कि इस असफलता से बचने के लिए AnotherClass का पुन: उपयोग नहीं करने के लिए परीक्षण को रद्द किया जा सकता है। यह जानबूझकर अधूरा निर्भरता ग्राफ बनाने की कोशिश नहीं कर रहा है।

pranavkm 13 मई 2016

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

dotnetjunkie 14 मई 2016

👍1

हां, यह विफल होना चाहिए लेकिन @pranavkm का कहना है कि यह विशिष्ट परीक्षण जानबूझकर

davidfowl 14 मई 2016

मैं इस बात से पूरी तरह सहमत हूं कि हमें इस परिदृश्य के लिए एक परीक्षण विशिष्ट की आवश्यकता है बजाय इसे कवर करने के दूसरे इरादे के साथ एक परीक्षण पर भरोसा करने की। यह नया परीक्षण हालांकि वर्तमान कार्यान्वयन के साथ नहीं होगा। आरसी 2 समय सीमा के भीतर इसे ठीक करने के लिए अभी भी समय है?

seesharper 14 मई 2016

आरटीएम के बाद इसे ठीक करना एक परिवर्तन है, जो सभी एडाप्टर कार्यान्वयन को भी तोड़ देगा।

dotnetjunkie 14 मई 2016

परीक्षण में जेनेरिक तर्क के रूप में एक स्ट्रिंग की आपूर्ति की गई थी, लेकिन इस प्रतिबद्ध में एक और क्लस्टर का उपयोग करने के लिए फिर से लिखा गया था।
https://github.com/aspnet/D dependencyInjection/commit/6a7bdda613c0cc526775b38532dedbffd2d2d6ac

संभावित समाधान जाने के लिए इस प्रतिबद्ध या सुनिश्चित करें कि परीक्षण रजिस्टर IFakeService कि AnotherClass निर्माता के लिए आवश्यक है कर रहे हैं।

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

अमूर्त एक अच्छी तरह से परिभाषित इंटरफेस के सेट के माध्यम से एक अनुबंध को परिभाषित करता है, लेकिन डिफ़ॉल्ट कार्यान्वयन का व्यवहार भी अनुबंध का हिस्सा है। यह केवल इकाई परीक्षणों के माध्यम से सत्यापित किया जा सकता है। ASP.NET Core, Entity Framework या किसी अन्य लाइब्रेरी में निर्भर किए जा रहे इस तरह के व्यवहार को एक यूनिट टेस्ट द्वारा कवर किया जाना चाहिए ताकि डेवलपर्स सुरक्षित रूप से डिफ़ॉल्ट कार्यान्वयन को दूसरे एडाप्टर के साथ बदल सकें जो आवश्यकताओं को पूरा करता है। इसका मतलब है टेस्ट पास करना। जिस मिनट आप व्यवहार को एक विनिर्देश परीक्षण द्वारा कवर नहीं करते हैं, तीसरे पक्ष के एडॉप्टर से किसी चीज के टूटने की संभावना होती है। वर्तमान में विनिर्देश पैकेज में 41 परीक्षण हैं और मुझे यह कहना है कि मैं थोड़ा चिंतित हूं जैसे कि इन परिक्षणों में हर परिदृश्य का हिसाब है। यहां तक कि लाइटइन्जेक्ट, जो एक अपेक्षाकृत सरल डीआई लाइब्रेरी है, को 500 से अधिक यूनिट परीक्षण मिले हैं।

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

मैं परीक्षण को पीआर में भी कर सकता हूं ताकि यह अधूरे ग्राफ को इंजेक्ट करने की कोशिश न करे।

पुनश्च: RC2 रिलीज पर बधाई :)

seesharper 14 मई 2016

👍5

लेकिन डिफ़ॉल्ट कार्यान्वयन का व्यवहार भी अनुबंध का हिस्सा है

dotnetjunkie 15 मई 2016

👍7

@ सेशपर हम निश्चित रूप से परीक्षण को बेहतर बनाने के लिए पीआर पर आपके साथ काम करने में प्रसन्न होंगे।

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

हमें एहसास होता है कि हमें Microsoft के डिजाइन और कार्यान्वयन में कुछ समझौता करना था। अंततः, सिस्टम की कमियों के बावजूद, हमने सिस्टम का उपयोग करने वाले लोगों से आम तौर पर सकारात्मक अनुभव देखा है। यहाँ उपयोग की जाने वाली DI प्रणाली का उद्देश्य अंत-सभी, सभी-कार्यान्वयन, _and भी नहीं-अंत-सभी, Be-all इंटरफ़ेस होना है। निस्संदेह कई परिदृश्य हैं जहां इस रेपो में कोड मदद नहीं करता है। और कोई भी "उपयोगकर्ता" कोड अंततः किसी भी DI कंटेनर का उपयोग कर सकता है जो वह चाहता है। यह ऐसे घटक हैं जो यहां अनुबंधों और / या कार्यान्वयन पर निर्भर करते हैं जो हमारे द्वारा की गई विभिन्न चर्चाओं में वर्णित कुछ सीमाएं हो सकती हैं।

Eilon 20 मई 2016

आइए इन क्षेत्रों में बेहतर कवरेज के लिए विनिर्देश परीक्षणों को अपडेट करें।

Eilon 25 मई 2016

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Dependencyinjection: अपूर्ण पंजीकरण के लिए संपत्ति इंजेक्शन विफल होना चाहिए

सबसे उपयोगी टिप्पणी

सभी 9 टिप्पणियाँ

संबंधित मुद्दों