टीडीडी

Question

करते समय अन्य वस्तुओं की खोज करना मैं टीडीडी का अभ्यास करने की कोशिश कर रहा हूं।

मेरे समझ कि TDD इस

1. तरह जाना चाहिए इंटरफेस/वर्ग मैं विकसित करने के लिए जा रहा हूँ के लिए एक परीक्षण सूची लिखें है।
2. मेरी टेस्ट सूची से सबसे आसान कार्यान्वित परीक्षण के साथ शुरू करें।
3. परीक्षण लिखें, अभी तक कोई कार्यान्वयन कोड नहीं है।
4. कोड संकलन करने के लिए कक्षा का इंटरफ़ेस लिखें।
5. परीक्षण चलाने के परिणामस्वरूप एक असफल परीक्षण।
6. परीक्षण पास करने के कार्यान्वयन को लिखें।
7. मैंने जो गड़बड़ी की है उसे दोबारा प्रतिक्रिया दें।
8. गोटो 2.

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

इस बिंदु पर एक वास्तविक टीडीडी क्या करना चाहिए?

1. थोड़ी देर के लिए अकेला मौजूदा परीक्षण सूची छोड़ दो और नई खोज वर्ग के लिए एक नया बना (एक ही समस्या स्पष्ट नजर जब नया वर्ग offcourse को लागू कर सकते हैं)
2. जाओ की सहभागिता के आधार रास्ता नई कक्षा का परीक्षण और नकल करें, जिस कक्षा में आप काम कर रहे हैं उसके टेस्टकेस के साथ जारी रखें और बाद में मॉक क्लास का सही कार्यान्वयन करने के लिए वापस आएं।
3. यह स्थिति खुद को पेश नहीं करनी चाहिए। मैंने शायद अपने शुरुआती डिजाइन को काफी अच्छी तरह से नहीं सोचा है। (लेकिन यह टीडीडी के प्रयोजनों में से किसी एक को पराजित नहीं करेगा ?!)।

मुझे यह जानना अच्छा लगेगा कि अन्य लोग इन स्थितियों को कैसे संभालेंगे।

Answer 1

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

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

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

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

Answer 2

आपको एक नकली कक्षा बनाना चाहिए। अनुमानित प्रतिकृतियों के साथ एक एकल इंटरफ़ेस। तो आप मूल का परीक्षण कर सकते हैं।

बाद में, आप नई कक्षा के साथ प्रक्रिया को दोहरा सकते हैं।

Answer 3

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

Answer 4

समस्या मेरे पास है कि जब मैं समय में कुछ बिंदु पर, बिंदु 6 & 7 पर पहुंचने मैं सदा ही निष्कर्ष है कि कार्यान्वयन मैं सिर्फ लिखा अन्य वर्ग को प्रत्यायोजित किया जाना चाहिए करने के लिए आते है।

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

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