यूनिट परीक्षण - क्या मैं इसे सही कर रहा हूं?

Question

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

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

FruitID FruitName FruitColor FruitCost 
    1   Apple  Red   1.2 
    2   Apple  Green  1.4 
    3   Apple  HalfHalf 1.5 

यह सब सिर्फ उदाहरण के लिए। लेकिन मान लें कि मेरे पास यह संरचना Fruit का संग्रह है (यह List<Fruit> है) इस संरचना में ऑब्जेक्ट्स। और मेरा तर्क संग्रह में फलों को पुन: व्यवस्थित करने के लिए कहेंगे यदि एक फल हटा दिया जाता है (यह केवल समाधान की आवश्यकता है)।

उदा। यदि 1 हटा दिया गया है, तो ऑब्जेक्ट 2 फल आईडी 1 लेता है, ऑब्जेक्ट 3 फल id2 लेता है।

अब मैं कोड Ive लिखा जो पुनर्व्यवस्था करता है परीक्षण करना चाहते हैं, आदि

मैं इस परीक्षण करना सेट कर सकते हैं?

---

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

यूनिट-परीक्षण के अनुसार: क्या मैं मूल रूप से यह सही तरीके से कर रहा हूं, या क्या मुझे गलत विचार है? और फिर यह सुनिश्चित करने के लिए कि विधि ठीक तरह से काम कर रही है, मैं अलग-अलग मूल्यवान वस्तुओं/डेटासेट को हटाने का परीक्षण करता हूं।

---

[Test] 
public void DeleteFruit() 
{ 
    var fruitList = CreateFruitList(); 
    var fm = new FruitManager(); 

    var resultList = fm.DeleteFruitTest("Apple", 2, fruitList); 

    //Assert that fruitobject with x properties is not in list ? how 
} 

private static List<Fruit> CreateFruitList() 
{ 
    //Build test data 
    var f01 = new Fruit {Name = "Apple",Id = 1, etc...}; 
    var f02 = new Fruit {Name = "Apple",Id = 2, etc...}; 
    var f03 = new Fruit {Name = "Apple",Id = 3, etc...}; 

    var fruitList = new List<Fruit> {f01, f02, f03}; 
    return fruitList; 
} 

Answer 1

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

हटाएं() विधि से आप क्या उम्मीद करेंगे? यदि आप 10 मिनट में "उत्पाद" हटाएं, तो गैर-विचारणीय व्यवहार में क्या शामिल होगा? खैर ... शायद यह तत्व को हटा देता है।

तो:

1) [Test] 
public void Fruit_Is_Removed_From_List_When_Deleted() 

जब कि परीक्षण लिखा है, पूरे TDD पाश के माध्यम से जाना (निष्पादित परीक्षण => लाल; => हरी इसे पारित करने के लिए बस इतना कोड लिखने, refactor => हरा)

इससे संबंधित महत्वपूर्ण बात यह है कि यदि विधि तर्क के रूप में पारित किया गया है तो सूची सूची में नहीं है, तो सूची सूची में नहीं है। तो अगली परीक्षण हो सकता है:

3) [Test] 
public void Fruit_Ids_Are_Reordered_When_Fruit_Is_Deleted() 

कि परीक्षण में क्या डाल करने के लिए:

2) [Test] 
public void Invalid_Fruit_Changes_Nothing_When_Deleted() 

अगला बात आपके द्वारा निर्दिष्ट है कि आईडी जब एक फल हटा दी जाती है पुन: व्यवस्थित किया जाना चाहिए? खैर, बस एक बुनियादी लेकिन प्रतिनिधि संदर्भ स्थापित करें जो साबित करेगा कि आपकी विधि अपेक्षित व्यवहार करती है।

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

तो फिर तुम त्रुटि या सीमा रेखा के मामलों के लिए इकाई परीक्षण बना सकते हैं:

4) [Test] 
public void Fruit_Ids_Arent_Reordered_When_Last_Fruit_Is_Deleted() 

5) [Test] 
[ExpectedException] 
public void Exception_Is_Thrown_When_Fruit_List_Is_Empty() 

...

Answer 2

इससे पहले कि आप वास्तव में अपने पहले टेस्ट लेखन शुरू, आप अपने ऐप की संरचना/डिजाइन के बारे में एक किसी न किसी विचार है करने वाले हैं, इंटरफेस आदि डिजाइन चरण अक्सर तरह की TDD साथ निहित है ।

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

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

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

Answer 3

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

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

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

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

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

@Update: चेकर विधि आंकड़ा संरचना पर एक संगतता जांच की अधिक है। आपके उदाहरण में, सूची में सभी फलों में लगातार आईडी हैं, इसलिए यह चेक किया गया है। यदि आपके पास डीएजी संरचना है, तो आप इसकी आइस्काइक्लिटी आदि देखना चाहेंगे,

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

Answer 4

चूंकि आप सी # का उपयोग कर रहे हैं, तो मुझे लगता है कि NUnit आपका परीक्षण ढांचा है। उस स्थिति में, आपके पास अपने निपटान में कई प्रकार के कथन [..] बयान हैं।

अपने कोड की बारीकियों के संबंध में

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

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

Answer 5

[Test] 
public void DeleteFruit() 
{ 
    var fruitList = CreateFruitList(); 
    var fm = new FruitManager(fruitList); 

    var resultList = fm.DeleteFruit(2); 

    //Assert that fruitobject with x properties is not in list 
    Assert.IsEqual(fruitList[2], fm.Find(2)); 
} 

private static List<Fruit> CreateFruitList() 
{ 
    //Build test data 
    var f01 = new Fruit {Name = "Apple",Id = 1, etc...}; 
    var f02 = new Fruit {Name = "Apple",Id = 2, etc...}; 
    var f03 = new Fruit {Name = "Apple",Id = 3, etc...}; 

    return new List<Fruit> {f01, f02, f03}; 
} 

आप फल सूची में से कुछ निर्भरता इंजेक्शन की कोशिश हो सकती है। फल प्रबंधक वस्तु एक क्रूड स्टोर है। तो यदि आपके पास एक डिलीट ऑपरेशन है तो आपको एक पुनर्प्राप्ति ऑपरेशन की आवश्यकता है।

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

[1 क संपादित करें]

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

Answer 6

यूनिट-परीक्षण के अनुसार: क्या मैं मूल रूप से यह सही तरीके से कर रहा हूं, या क्या मुझे गलत विचार है?

आप नाव से चूक गए हैं।

मैं काफी नहीं मिल कैसे परीक्षण कोड से पहले हो जाता है अगर आप क्या संरचनाओं नहीं जानते हैं और आप डेटा

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

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

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

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

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

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

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

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

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

अनुशंसित पढ़ना फ्रीमैन/प्राइस, बढ़ते वस्तु उन्मुख सॉफ्टवेयर, तक टेस्ट

Answer 7

प्रारंभ इंटरफेस के साथ प्रेरित होकर, एक कंकाल ठोस कार्यान्वयन है।प्रत्येक विधि/संपत्ति/घटना/कन्स्ट्रक्टर के लिए, अपेक्षित व्यवहार है। पहले व्यवहार के लिए एक विनिर्देशन के साथ प्रारंभ करें, और पूरा यह:

[विशिष्टता] एक ही है [TestFixture] के रूप में [यह] के रूप में [टेस्ट]

[Specification] 
When_fruit_manager_has_delete_called_with_existing_fruit : FruitManagerSpecifcation 
{ 
    private IEnumerable<IFruit> _fruits; 

    [It] 
    public void Should_remove_the_expected_fruit() 
    { 
    Assert.Inconclusive("Please implement"); 
    } 

    [It] 
    public void Should_not_remove_any_other_fruit() 
    { 
    Assert.Inconclusive("Please implement"); 
    } 

    [It] 
    public void Should_reorder_the_ids_of_the_remaining_fruit() 
    { 
    Assert.Inconclusive("Please implement"); 
    } 

    /// <summary> 
    /// Setup the SUT before creation 
    /// </summary> 
    public override void GivenThat() 
    { 
    _fruits = new List<IFruit>(); 

    3.Times(_fruits.Add(Mock<IFruit>())); 

    this._fruitToDelete = _fruits[1]; 

    // this fruit is injected in th Sut 
    Dep<IEnumerable<IFruit>>() 
       .Stub(f => ((IEnumerable)f).GetEnumerator()) 
       .Return(this.Fruits.GetEnumerator()) 
       .WhenCalled(mi => mi.ReturnValue = this._fruits.GetEnumerator()); 

    } 

    /// <summary> 
    /// Delete a fruit 
    /// </summary> 
    public override void WhenIRun() 
    { 
    Sut.Delete(this._fruitToDelete); 
    } 
} 

ऊपर विशिष्टता सिर्फ सहारा है और एक ही है शामिल है, लेकिन यह प्रत्येक इकाई/विनिर्देश के निकट आने का एक अच्छा व्यवहार टीडीडी तरीका है।

public interface IFruitManager 
{ 
    IEnumerable<IFruit> Fruits { get; } 

    void Delete(IFruit); 
} 

public class FruitManager : IFruitManager 
{ 
    public FruitManager(IEnumerable<IFruit> fruits) 
    { 
    //not implemented 
    } 

    public IEnumerable<IFruit> Fruits { get; private set; } 

    public void Delete(IFruit fruit) 
    { 
    // not implemented 
    } 
} 

तो जैसा कि आप देख सकते हैं कोई वास्तविक कोड लिखा है:

यहाँ लागू नहीं किया गया SUT जब आप पहली बार इस पर काम शुरू का हिस्सा होगा। यदि आप पहले "जब _..." विशिष्टता को पूरा करना चाहते हैं, तो आपको वास्तव में पहले [कन्स्ट्रक्टर स्पेसिफिकेशन] करना होगा जब_फ्रूट_मैनेजर_आईएस_इनजेक्टेड_with_fruit() क्योंकि इंजेक्शन वाले फलों को फलों की संपत्ति को सौंपा नहीं जा रहा है।

तो voila, पहले वास्तविक रूप से लागू करने के लिए कोई वास्तविक कोड आवश्यक नहीं है ... अब केवल एक चीज की आवश्यकता अनुशासन है।

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