असली दुनिया परियोजना में टीडीडी शुरुआती बिंदु कैसे चुनें?

Question

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

NotificationClient client = new NotificationClient("abcd1234"); // client ID 
Response code = client.notifyOnEvent(Event.LIMIT_REACHED, 100); // some params of call 

पर्दे के पीछे कुछ अनुवाद और संदेश स्वरूप तैयारी नहीं है, इसलिए मैं अपने ग्राहक क्षुधा से छिपाना चाहते हैं।

मुझे नहीं पता कि कहां और कैसे शुरू किया जाए। क्या मुझे इस पुस्तकालय के लिए कुछ मोटे वर्ग सेट करना चाहिए? मैं

public void testClientSendInvalidEventCommand() { 
    NotificationClient client = new NotificationClient(...); 
    Response code = client.notifyOnEvent(Event.WRONG_EVENT); 
    assertEquals(1223, code.codeValue()); 
} 

नीचे के रूप में परीक्षण NotificationClient साथ आरंभ करना चाहिए ताकि, इस तरह के परीक्षण के साथ मैं पूरा काम कर रहे कार्यान्वयन एक ही बार में लिखने के लिए, TDD राज्यों के रूप में कोई बच्चा चरणों के साथ मजबूर कर रहा हूँ है। मैं क्लाइंट में सोसमिंग कर सकता हूं लेकिन फिर मुझे इस बात को जानना होगा कि इसे आगे बढ़ाया जाए, इसलिए मुझे कुछ आगे की इच्छा बनाने की ज़रूरत है।

शायद मुझे नीचे से शुरू करना चाहिए, पहले इस संदेश स्वरूपण घटक का परीक्षण करें और फिर इसे सही क्लाइंट परीक्षण में उपयोग करें?

सही तरीका क्या है? क्या हमें हमेशा शीर्ष से शुरू करना चाहिए (इस विशाल चरण से निपटने के लिए कैसे आवश्यक है)? क्या हम वांछित फीचर (इस उदाहरण में फॉर्मेटर के रूप में) के छोटे हिस्से को महसूस करने वाले किसी वर्ग के साथ शुरू कर सकते हैं?

यदि मुझे पता चलेगा कि मेरे परीक्षणों के साथ कहां मारा जाए तो मेरे लिए आगे बढ़ना बहुत आसान होगा।

Answer 1

acceptance tests को भ्रमित न करें जो आपके आवेदन के प्रत्येक छोर पर है, और unit tests के साथ executable specifications बनाएं।

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

परीक्षण करने और उन्हें सही ढंग से समझने के लिए उन्हें विभाजित करने से पहले कितनी जटिल चीजें मिलती हैं, इसे टेस्ट ड्राइव डिज़ाइन कहा जाता है।

Answer 2

टीडीडी का एक लक्ष्य यह है कि परीक्षण डिजाइन को सूचित करता है। तो तथ्य यह है कि आपको अपने NotificationClient को कार्यान्वित करने के बारे में सोचना चाहिए, यह एक अच्छी बात है; यह आपको सामने (आशावादी) सरल abstractions के बारे में सोचने के लिए मजबूर करता है।

इसके अलावा, टीडीडी प्रकार निरंतर रिफैक्टरिंग मानता है। आपका पहला समाधान शायद अंतिम नहीं होगा; इसलिए जब आप अपने कोड को परिष्कृत करते हैं तो परीक्षण आपको बताते हैं कि त्रुटियों को संकलित करने से वास्तविक रनटाइम समस्याओं में क्या ब्रेक होता है।

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

Answer 3

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

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

Answer 4

मैं इस लाइन के साथ शुरू होता है:

NotificationClient client = new NotificationClient("abcd1234"); // client ID 

ऐसा लगता है कि हम एक NotificationClient है, जो एक ग्राहक आईडी की जरूरत की जरूरत है। परीक्षण करने के लिए यह एक आसान बात है। मेरा पहला परीक्षण की तरह कुछ दिख सकता है:

public void testNewClientAbcd1234HasClientId() { 
    NotificationClient client = new NotificationClient("abcd1234"); 
    assertEquals("abcd1234", client.clientId()); 
} 

बेशक, यह पहली बार में संकलन नहीं होगा - नहीं, जब तक मैं एक निर्माता है कि एक स्ट्रिंग पैरामीटर और एक clientid() विधि लेता है के साथ एक NotificationClient वर्ग लिखा था कि एक स्ट्रिंग देता है - लेकिन यह टीडीडी चक्र का हिस्सा है।

public class NotificationClient { 
    public NotificationClient(string clientId) { 
    } 
    public string clientId() { 
     return ""; 
    } 
} 

इस बिंदु पर, मैं अपने परीक्षण चला सकते हैं और यह असफल घड़ी (क्योंकि मैं हार्ड-कोडेड clientid() के बदले है खाली स्ट्रिंग के लिए)। एक बार जब मैं अपने में नाकाम रहने इकाई परीक्षण मिल गया है, मैं पारित करने के लिए परीक्षण पाने के लिए (NotificationClient में) सिर्फ पर्याप्त उत्पादन कोड लिखें:

public string clientId() { 
     return "abcd1234"; 
    } 

अब मेरे सभी परीक्षण पास, तो मैं विचार कर सकते हैं कि आगे क्या करना।

public void testNewClientBcde2345HasClientId() { 
    NotificationClient client = new NotificationClient("bcde2345"); 
    assertEquals("bcde2345", client.clientId()); 
} 

मैं अपने परीक्षण सूट चलाने के लिए और देख सकते हैं कि testNewClientBcde2345HasClientId() विफल रहता है: स्पष्ट (अच्छी तरह से, मुझे के लिए स्पष्ट) अगले कदम यह सुनिश्चित करें कि मैं ग्राहकों जिसका आईडी "abcd1234" का उपयोग नहीं है बना सकते हैं बनाने के लिए है जबकि testNewClientAbcd1234HasClientId() से गुजरता है, और अब मैं NotificationClient के एक सदस्य चर जोड़ने के लिए एक अच्छा कारण मिल गया है:

public class NotificationClient { 
    private string _clientId; 
    public NotificationClient(string clientId) { 
     _clientId = clientId; 
    } 
    public string clientId() { 
     return _clientId; 
    } 
} 

कोई टंकण त्रुटि मानते हुए में snuck है, कि मेरे सभी परीक्षण पास करने के मिल जाएगा, और मैं अगले कदम पर जो भी हो सकता है। (आपके उदाहरण में, यह शायद परीक्षण करेगा कि notifyOnEvent(Event.WRONG_EVENT)Response देता है जिसका codeValue() 1223 के बराबर है।)

क्या इससे कोई मदद मिलती है?