इकाई परीक्षणों में अशक्त मापदंडों के साथ वस्तुओं का निर्माण करना ठीक है?

Question

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

मैं सोच रहा था कि क्या यूनिट परीक्षणों में ऑब्जेक्ट्स कंस्ट्रक्टर्स को अशक्त तर्क प्रदान करने में कुछ गड़बड़ है। मुझे कुछ उदाहरण कोड प्रदान करते हैं:

public class CarRadio
{...}


public class Motor
{
    public void SetSpeed(float speed){...}
}


public class Car
{
    public Car(CarRadio carRadio, Motor motor){...}
}


public class SpeedLimit
{
    public bool IsViolatedBy(Car car){...}
}

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

public class SpeedLimitTest
{
    public void TestSpeedLimit()
    {
        Motor motor = new Motor();
        motor.SetSpeed(10f);
        Car car = new Car(null, motor);

        SpeedLimit speedLimit = new SpeedLimit();
        Assert.IsTrue(speedLimit.IsViolatedBy(car));
    }
}

परीक्षण ठीक चलता है। अपनी बात करने के लिए SpeedLimitएक के Carसाथ की जरूरत Motorहै। यह बिल्कुल भी दिलचस्पी नहीं है CarRadio, इसलिए मैंने इसके लिए अशक्तता प्रदान की।

मैं सोच रहा था कि एक वस्तु पूरी तरह से निर्मित किए बिना सही कार्यक्षमता प्रदान करती है, जो एसआरपी या एक कोड गंध का उल्लंघन है। मुझे यह अहसास है कि यह करता है, लेकिन यह भी speedLimit.IsViolatedBy(motor)सही नहीं लगता है - एक गति सीमा का उल्लंघन कार द्वारा किया जाता है, मोटर नहीं। हो सकता है कि मुझे केवल यूनिट परीक्षणों बनाम काम करने वाले कोड के लिए एक अलग दृष्टिकोण की आवश्यकता है, क्योंकि पूरे इरादे केवल पूरे हिस्से का परीक्षण करना है।

क्या यूनिट के परीक्षण में अशक्त वस्तुओं का निर्माण एक कोड गंध है?

Comments

थोड़ा ऑफ-टॉपिक, लेकिन Motorशायद बिल्कुल भी नहीं होना चाहिए speed। यह एक होना चाहिए throttleऔर torqueवर्तमान के आधार पर गणना करता है rpmऔर throttle। यह कार का काम है Transmissionकि इसे एक वर्तमान गति में एकीकृत करने के लिए उपयोग किया जाए, और इसे rpmवापस सिग्नल में बदलने के लिए Motor... लेकिन मुझे लगता है, आप यथार्थवाद के लिए वैसे भी इसमें नहीं थे, क्या आप थे?

— सेमीस्टर

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

— टॉमी

नल-ऑब्जेक्ट पैटर्न पर विचार करें । यह अक्सर कोड को सरल करता है, जबकि इसे NPE-safe भी बनाता है।

— बाकूउ

बधाई : आपने परीक्षण किया है कि एक nullरेडियो के साथ , गति सीमा सही ढंग से गणना की जाती है। अब आप रेडियो के साथ गति सीमा को मान्य करने के लिए एक परीक्षण बनाना चाहते हैं ; बस इस मामले में व्यवहार अलग है ...

— Matthieu M.

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

— ओवेन

Answer 1

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

हालांकि, चलो एक अलग उदाहरण लेते हैं - आइए एक पर विचार करें SteeringWheel। मान लेते हैं कि ए Carके पास एक है SteeringWheel, लेकिन गति परीक्षण वास्तव में इसकी परवाह नहीं करता है। इस मामले में, मैं एक अशक्त नहीं होगा SteeringWheelक्योंकि यह तब Carकक्षा को उन स्थानों पर धकेल रहा है जहां इसे जाने के लिए डिज़ाइन नहीं किया गया है। इस मामले में, आप किसी प्रकार का DefaultSteeringWheelनिर्माण (जिसमें रूपक जारी रखने के लिए) को एक सीधी रेखा में बंद करना बेहतर होगा ।

Comments

और यह जांचने के लिए एक यूनिट टेस्ट लिखना न भूलें कि Carबिना निर्माण नहीं किया जा सकता SteeringWheel...

— cmaster

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

— एक इयरविग

सेल्फ ड्राइविंग कारों में स्टीयरिंग व्हील नहीं हो सकता है। बस केह रहा हू। Ack

— ब्लैकजैक

@James_Parsons मैं यह जोड़ना भूल गया कि यह एक ऐसे वर्ग के बारे में था जिसके पास अशक्त जांच नहीं थी क्योंकि यह केवल आंतरिक रूप से उपयोग किया गया था और हमेशा गैर-शून्य पैरामीटर प्राप्त किया था। अन्य तरीकों ने Carएक NRE को एक अशक्त के साथ फेंक दिया होगा CarRadio, लेकिन संबंधित कोड के लिए SpeedLimitनहीं होगा। प्रश्न के मामले में अब आप सही होंगे और मैं वास्तव में ऐसा करूंगा।

— आर। शमित्ज़

@mtraceur जिस तरह से हर किसी ने माना कि एक अशक्त तर्क के साथ निर्माण की अनुमति देने वाले वर्ग का मतलब है एक वैध विकल्प मुझे यह एहसास दिलाता है कि मुझे शायद वहाँ अशक्त जाँच करनी चाहिए। उसके बाद मेरा जो वास्तविक मुद्दा था वह बहुत सारे अच्छे, रोचक, लिखित उत्तरों से ढंका है, जिन्हें मैं बर्बाद नहीं करना चाहता और जिसने मेरी मदद की। इस उत्तर को भी अब स्वीकार कर रहा हूं क्योंकि मैं चीजों को अधूरा छोड़ना पसंद नहीं करता हूं और यह सबसे अधिक उत्कीर्ण है (हालांकि वे सभी सहायक थे)।

— आर। शमित्ज़

Answer 2

क्या यूनिट के परीक्षण में अशक्त वस्तुओं का निर्माण एक कोड गंध है?

हाँ। कोड गंध की C2 परिभाषा पर ध्यान दें : "एक कोडस्मेल एक संकेत है कि कुछ गलत हो सकता है, निश्चितता नहीं।"

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

यदि आप यह प्रदर्शित करने की कोशिश कर रहे हैं कि speedLimit.IsViolatedBy(car)यह CarRadioकंस्ट्रक्टर को दिए गए तर्क पर निर्भर नहीं करता है , तो संभवतः भविष्य के अनुचर को यह स्पष्ट करना होगा कि वह टेस्ट डबल शुरू करने से उस बाधा को स्पष्ट करे जो परीक्षण में विफल हो जाता है यदि इसे लागू किया जाता है।

यदि, जैसा कि अधिक संभावना है, तो आप बस अपने आप को बचाने की कोशिश कर रहे हैं जो CarRadioकि आप जानते हैं कि इस मामले में उपयोग नहीं किया गया है, आपको इस पर ध्यान देना चाहिए

• यह एनकैप्सुलेशन का उल्लंघन है (आप इस तथ्य को बता रहे हैं CarRadioजिसका उपयोग परीक्षण में लीक नहीं हुआ है)
• आपने कम से कम एक मामले की खोज की है जहाँ आप एक Carनिर्दिष्ट किए बिना बनाना चाहते हैंCarRadio

मुझे दृढ़ता से संदेह है कि कोड आपको यह बताने की कोशिश कर रहा है कि आप एक निर्माता चाहते हैं जो दिखता है

public Car(IMotor motor) {...}

और फिर वह निर्माता यह तय कर सकता है कि इस तथ्य के साथ क्या करना है कि कोई भी नहीं हैCarRadio

public Car(IMotor motor) {
    this(null, motor);
}

या

public Car(IMotor motor) {
    this( new ICarRadio() {...} , motor);
}

या

public Car(IMotor motor) {
    this( new DefaultRadio(), motor);
}

आदि।

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

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

यह एक संकेत हो सकता है जिसे SpeedLimit.isViolatedByएक भूमिका इंटरफ़ेस को स्वीकार करना चाहिए जो कार को लागू करता है , बजाय एक पूरी कार की आवश्यकता के।

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeedवास्तव में घटिया नाम है; उम्मीद है कि आपकी डोमेन भाषा में सुधार होगा।

उस इंटरफ़ेस के साथ, आपका परीक्षण SpeedLimitबहुत सरल हो सकता है

public void TestSpeedLimit()
{
    IHaveSpeed somethingTravelingQuickly = new IHaveSpeed {
        float speed() { return 10f; }
    }

    SpeedLimit speedLimit = new SpeedLimit();
    Assert.IsTrue(speedLimit.IsViolatedBy(somethingTravelingQuickly));
}

Comments

आपके अंतिम उदाहरण में, मुझे लगता है कि आपको एक मॉक क्लास बनाना होगा जो IHaveSpeedइंटरफ़ेस को कम से कम लागू करता है (कम से कम c #) में आप स्वयं एक इंटरफ़ेस को इंस्टाल नहीं कर पाएंगे।

— रयान सियरले

यह सही है - प्रभावी वर्तनी इस बात पर निर्भर करेगी कि आप अपने परीक्षणों के लिए ब्लूब के किस स्वाद का उपयोग कर रहे हैं।

— VoiceOfUnreason

Answer 3

क्या यूनिट के परीक्षण में अशक्त वस्तुओं का निर्माण एक कोड गंध है?

नहीं

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

एक और सवाल यह है कि जब आप पास होते हैं तो क्या होता है NULL। लेकिन यह वही है जो एक इकाई परीक्षण के बारे में है: यह सुनिश्चित करना कि प्रत्येक संभावित इनपुट के लिए एक परिभाषित परिणाम हो रहा है। और NULL है तो आप एक परिभाषित परिणाम होना चाहिए और आप उस के लिए एक परीक्षण करना चाहिए था, एक संभावित इनपुट।

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

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

---

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

Comments

ऐसा लगता है जैसे आप Carयहां बाउट टेस्ट लिख रहे हैं। जबकि मुझे ऐसा कुछ भी दिखाई नहीं दे रहा है जिसे मैं गलत कथन मानूंगा, सवाल परीक्षण के बारे में है SpeedLimit।

— आर। शमित्ज़

@ R.Schmitz आप क्या मतलब यकीन नहीं है। मैंने प्रश्न उद्धृत किया है, यह किसके NULLकंस्ट्रक्टर के पास है Car।

— नवगीत

इसके बारे में अगर परीक्षण के दौरानSpeedLimit कुछ और करने के लिए अशक्त गुजर रहा है । आप देख सकते हैं कि परीक्षण को "स्पीडलिमिटटेस्ट" कहा जाता है और केवल Assertएक विधि की जाँच कर रहा है SpeedLimit। परीक्षण Car- उदाहरण के लिए "यदि आपकी कार को रेडियो के बिना निर्माण योग्य माना जाता है, तो आपको उसके लिए एक परीक्षण लिखना चाहिए" - एक अलग परीक्षण में होगा।

— आर। शमित्ज़

Answer 4

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

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

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

यह कहने के बाद, यह एक गैर-मुद्दा बन जाता है, जब आप दो काम करते हैं:

1. कक्षाओं के बजाय इंटरफेस के लिए कार्यक्रम।
2. नल के बजाय नकली निर्भरता को इंजेक्ट करने के लिए एक मॉकिंग फ्रेमवर्क (जैसे Moq for C #) का उपयोग करें।

तो आपके उदाहरण के लिए आपके पास होगा:

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Moq का उपयोग करने के बारे में अधिक विवरण यहां पाया जा सकता है ।

बेशक, यदि आप इसे पहले बिना मॉकिंग के समझना चाहते हैं, तो आप तब भी कर सकते हैं, जब तक आप इंटरफेस का उपयोग कर रहे हैं। बस एक डमी CarRadio और मोटर निम्नलिखित के रूप में बनाएँ, और इसके बजाय उन लोगों को इंजेक्ट करें:

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

Comments

यह उत्तर मैंने लिखा है

— Liath

मैं यहां तक ​​कहूंगा कि डमी वस्तुओं को भी अपना अनुबंध पूरा करना होगा। यदि IMotorएक getSpeed()विधि थी, तो DummyMotorएक सफल होने के बाद एक संशोधित गति को वापस करने की आवश्यकता होगी setSpeed।

— कॉमरफिक

Answer 5

यह सिर्फ ठीक नहीं है, यह एक प्रसिद्ध हार्दिक तकनीक है जो एक टेस्ट हार्नेस में विरासत कोड प्राप्त करने के लिए है। (माइकल पंख द्वारा "लिगेसी कोड के साथ प्रभावी रूप से कार्य करना" देखें।)

क्या इसमें बदबू आती है? कुंआ...

परीक्षण गंध नहीं करता है। परीक्षा अपना काम कर रही है। यह घोषणा कर रहा है "यह वस्तु अशक्त हो सकती है और परीक्षण के तहत कोड अभी भी सही ढंग से काम करता है"।

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

Answer 6

आइए पहले सिद्धांतों पर वापस जाएं।

एक इकाई परीक्षण एकल वर्ग के कुछ पहलू का परीक्षण करता है।

हालांकि, ऐसे निर्माता या विधियाँ होंगी जो अन्य वर्गों को मापदंडों के रूप में लेते हैं। आप इन्हें कैसे संभालते हैं, यह केस से केस में अलग-अलग होगा, लेकिन सेटअप कम से कम होना चाहिए क्योंकि वे ऑब्जेक्टिव हैं। ऐसे परिदृश्य हो सकते हैं जहां NULL पैरामीटर पास करना पूरी तरह से मान्य है - जैसे कि कार जिसमें कोई रेडियो न हो।

मैं यहाँ यह मान रहा हूँ, कि हम केवल कार लाइन को शुरू करने के लिए (कार थीम को जारी रखने के लिए) परीक्षण कर रहे हैं, लेकिन आप यह भी जाँचने के लिए अन्य मानकों को NULL पास करना चाह सकते हैं कि कोई भी रक्षात्मक कोड और अपवाद सौंपने वाले तंत्र के रूप में कार्य कर रहे हैं की आवश्यकता है।

अब तक सब ठीक है। हालाँकि, अगर NULL का कोई मान नहीं है , तो क्या होगा । ठीक है, यहाँ आप नकली, स्टब, डमी और नकली की नकली दुनिया में हैं ।

यदि यह सब कुछ बहुत अधिक लगता है, तो आप वास्तव में पहले से ही कार निर्माता में NULL को पास करके एक डमी का उपयोग कर रहे हैं क्योंकि यह संभावित रूप से उपयोग नहीं किया जाएगा।

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

Comments

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

— एंट पी

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

— एंट पी

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

— एंट पी

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

— एंट पी

RobbieDee - मैं सटीक विपरीत के बारे में बात कर रहा हूं। इस बात पर विचार करें कि आप एक आम गलतफहमी का शिकार हो सकते हैं, इस बात पर फिर से गौर करें कि आप "यूनिट" को क्या मानते हैं और हो सकता है कि केंट बेक वास्तव में टीडीडी के बारे में बात करते समय थोड़ा गहराई से खुदाई करें। ज्यादातर लोग जिसे अब TDD कहते हैं, वह कार्गो पंथ राक्षसी है। youtube.com/watch?v=EZ05e7EMOLM

— Ant P

Answer 7

आपके डिज़ाइन पर एक नज़र डालते हुए, मैं सुझाव दूंगा कि Carयह एक सेट से बना है Features। एक फ़ीचर शायद ए CarRadio, या EntertainmentSystemजिसमें ए CarRadio, DvdPlayerआदि जैसी चीज़ें शामिल हो सकती हैं ।

तो, कम से कम, आपको Carएक सेट के साथ निर्माण करना होगा Features। EntertainmentSystemऔर CarRadioइंटरफ़ेस (Java, C # etc) के कार्यान्वयनकर्ता होंगे public [I|i]nterface Featureऔर यह कम्पोज़िट डिज़ाइन पैटर्न का एक उदाहरण होगा।

इसलिए, आप हमेशा एक के Carसाथ निर्माण करेंगे Featuresऔर एक इकाई परीक्षण Carबिना किसी के बिना कभी नहीं होगा Features। यद्यपि आप BasicTestCarFeatureSetअपने सबसे बुनियादी परीक्षण के लिए आवश्यक कार्यक्षमता का न्यूनतम सेट रखने का विचार कर सकते हैं ।

बस कुछ विचार।

जॉन