एक साल पहले मैं काम से 9 महीने की छुट्टी लेने में सक्षम होने के लिए भाग्यशाली था। मैंने तय किया कि उस समय में मैं अपने सी # कौशल को सुधारूंगा। मैंने परियोजनाओं के एक समूह पर काम करना शुरू किया और अपने आप को टीडीडी का पालन करने के लिए मजबूर किया।
यह काफी ज्ञानवर्धक प्रक्रिया थी।
यह पहली बार में कठिन था, लेकिन समय के साथ मैंने सीखा कि अधिक परीक्षण योग्य कोड कैसे लिखें (जो, जैसा कि यह पता चला है, अधिक ठोस कोड हो जाता है) और इस प्रक्रिया में मैंने अपने ओओ डिजाइन कौशल को भी तेज किया।
अब मैं कार्यबल में वापस आ गया हूं और कुछ अजीब देख रहा हूं।
मैं टीडीडी का पालन नहीं करना पसंद करता हूं।
मुझे पता है कि टीडीडी मुझे धीमा कर देता है और वास्तव में एक साफ आवेदन डिजाइन करना कठिन हो जाता है।
इसके बजाय, मैंने थोड़ा (बड़े पैमाने पर) अलग दृष्टिकोण अपनाया है:
- काम का एक ऊर्ध्वाधर टुकड़ा उठाओ
- एक कार्यशील प्रोटोटाइप विकसित करें
- सब कुछ अच्छा और सुव्यवस्थित होने तक रिफ्लेक्टर
- मेरे द्वारा लिखे गए खूबसूरती से ठोस और परीक्षण योग्य कोड की सराहना करें।
आपने देखा होगा कि चरण 1 "मेरे परीक्षण लक्ष्य की सार्वजनिक सतह को परिभाषित नहीं करता था" और चरण 2 में "उक्त सार्वजनिक सतह से बेजेस का परीक्षण नहीं किया गया था।" आपने यह भी देखा होगा कि परीक्षण में कोई भी कदम शामिल नहीं है। मैं परीक्षण योग्य कोड लिख रहा हूं, लेकिन मैं इसका परीक्षण नहीं कर रहा हूं ... अभी तक।
अब, मैं यह स्पष्ट करना चाहता हूं कि मैं वास्तव में किसी भी प्रकार के परीक्षण का उपयोग नहीं कर रहा हूं। मैं जो कोड लिख रहा हूं वह काम करता है । यह काम करता है क्योंकि मैं इसे मैन्युअल रूप से परीक्षण कर रहा हूं।
मैं यह भी स्पष्ट करना चाहूंगा कि मैं सभी स्वचालित परीक्षण का उपयोग नहीं कर रहा हूँ। यह वह जगह है जहाँ मेरी प्रक्रिया अलग है। और यही कारण है कि मैं यह सवाल पूछ रहा हूं।
सिद्धांत में TDD। व्यवहार में नहीं।
मेरी प्रक्रिया थोड़ी विकसित हुई है और मैंने TDD और बिना किसी परीक्षण के बीच एक संतुलन बनाया है, जो मुझे बहुत उपयोगी लगता है और यथोचित सुरक्षित भी है। यह इस प्रकार है:
- काम के परीक्षण में काम कर रहे ऊर्ध्वाधर टुकड़ा को ध्यान में रखते हुए लागू करें, लेकिन कोई परीक्षण न लिखें।
- यदि नीचे सड़क (जैसे, एक महीने बाद) कि स्लाइस में संशोधन की आवश्यकता है
- यूनिट टेस्ट, इंटीग्रेशन टेस्ट, बिहेवियर टेस्ट आदि लिखें जो काम के स्लाइस की गारंटी देते हैं
- कोड को संशोधित करें
- यदि उस स्लाइस में संशोधन की आवश्यकता नहीं है,
- कुछ मत करो
बस से पहले से परीक्षण लेखन का बोझ स्थानांतरण करके लिख से पहले करने के लिए कोड को संशोधित कोड मैं और अधिक काम करने वाले कोड का उत्पादन कर लिया है। और, जब मैं परीक्षण लिखने के लिए इधर-उधर होता हूं तो मैं उनमें से बहुत कम लिखता हूं लेकिन लगभग जमीन (उच्च आरओआई) को कवर करता हूं।
मुझे यह प्रक्रिया पसंद है, लेकिन मुझे चिंता है कि यह अच्छी तरह से पैमाने पर नहीं हो सकता है। इसकी सफलता डेवलपर्स में चीजों को बदलने से पहले परीक्षण लिखने के बारे में मेहनती होने पर टिका है। और यह एक बहुत बड़ा जोखिम लगता है। लेकिन, TDD में एक ही जोखिम है।
तो, क्या मैं [बीटी] डीडी नरक में जा रहा हूं, या यह व्यावहारिक कोडिंग और परीक्षण का एक सामान्य रूप है?
मैं इस तरह काम करते रहना चाहूंगा। मैं लंबी अवधि में इस प्रक्रिया को काम करने के लिए क्या कर सकता हूं?
ध्यान दें:मैं अपनी परियोजनाओं पर एकमात्र डेवलपर हूं और मैं हर चीज के लिए जिम्मेदार हूं: आवश्यकताएं इकट्ठा करना, डिजाइन, वास्तुकला, परीक्षण, तैनाती, आदि। मुझे संदेह है कि मेरी प्रक्रिया क्यों काम कर रही है।
If that slice doesn't need modification। lizkeogh.com/2012/06/24/beyond-test-driven-development