TDD के साथ एक शानदार YES (और कुछ अपवादों के साथ)
विवादास्पद ठीक है, लेकिन मेरा तर्क है कि जो कोई भी इस प्रश्न का उत्तर 'नहीं' दे रहा है, उसे TDD की मौलिक अवधारणा याद आ रही है।
मेरे लिए, यदि आप TDD का अनुसरण करते हैं, तो उत्तर एक शानदार हां है । यदि आप नहीं हैं तो कोई प्रशंसनीय उत्तर नहीं है।
TDD में DDD
TDD को अक्सर आपको मुख्य लाभ के रूप में उद्धृत किया जाता है।
- रक्षा
- कोड सुनिश्चित करना बदल सकता है लेकिन उसका व्यवहार नहीं ।
- यह कभी भी रिफैक्टिंग के इतने महत्वपूर्ण अभ्यास की अनुमति देता है ।
- आप इस TDD को हासिल करें या न करें।
- डिज़ाइन
- आप निर्दिष्ट करते हैं कि कुछ क्या करना चाहिए, इसे लागू करने से पहले कैसे व्यवहार करना चाहिए ।
- यह अक्सर अधिक सूचित कार्यान्वयन निर्णयों का अर्थ है ।
- प्रलेखन
- परीक्षण सूट को विनिर्देश (आवश्यकताओं) के प्रलेखन के रूप में कार्य करना चाहिए ।
- इस तरह के उद्देश्य के लिए परीक्षणों का उपयोग करने का मतलब है कि प्रलेखन और कार्यान्वयन हमेशा सुसंगत स्थिति में होते हैं - एक के लिए एक परिवर्तन का मतलब दूसरे के लिए एक परिवर्तन है। आवश्यकताओं और डिजाइन को अलग-अलग शब्द दस्तावेज़ पर रखने के साथ तुलना करें।
कार्यान्वयन से अलग जिम्मेदारी
प्रोग्रामर के रूप में, यह बहुत महत्वपूर्ण है कि विशेषताओं के महत्व के बारे में सोचने के लिए और कुछ ओवरहेड के रूप में गेटर्स और सेटर।
लेकिन विशेषताएँ एक कार्यान्वयन विवरण हैं, जबकि बसने वाले और गेटर्स एक संविदात्मक इंटरफ़ेस हैं जो वास्तव में कार्यक्रमों को काम करते हैं।
किसी वस्तु पर वर्तनी के लिए यह अधिक महत्वपूर्ण है:
अपने ग्राहकों को इसकी स्थिति बदलने की अनुमति दें
तथा
अपने ग्राहकों को इसकी स्थिति के बारे में बताने की अनुमति दें
फिर यह राज्य वास्तव में कैसे संग्रहीत किया जाता है (जिसके लिए एक विशेषता सबसे आम है, लेकिन एकमात्र तरीका नहीं है)।
एक परीक्षण जैसे
(The Painter class) should store the provided colour
TDD के प्रलेखन भाग के लिए महत्वपूर्ण है ।
तथ्य यह है कि अंतिम कार्यान्वयन तुच्छ (विशेषता) है और जब आप परीक्षण लिखते हैं तो कोई रक्षा लाभ नहीं होता है।
राउंड-ट्रिप इंजीनियरिंग की कमी ...
सिस्टम डेवलपमेंट वर्ल्ड में प्रमुख समस्याओं में से एक राउंड-ट्रिप इंजीनियरिंग 1 की कमी है - एक सिस्टम की डेवलपमेंट प्रक्रिया असंतुष्ट उप-प्रक्रियाओं में खंडित हो जाती है जिसमें (प्रलेखन, कोड) अक्सर असंगत होते हैं।
1 ब्रॉडी, माइकल एल। "जॉन मायलोपोलोस: वैचारिक मॉडलिंग के बीज बोना।" वैचारिक मॉडलिंग: नींव और अनुप्रयोग। स्प्रिंगर बर्लिन हीडलबर्ग, 2009. 1-9।
... और टीडीडी इसे कैसे हल करता है
यह टीडीडी का प्रलेखन हिस्सा है जो यह सुनिश्चित करता है कि सिस्टम और इसके कोड के विनिर्देश हमेशा सुसंगत हैं।
पहले डिजाइन करें, बाद में लागू करें
टीडीडी के भीतर हम पहले असफलता परीक्षण लिखते हैं, उसके बाद ही कोड लिखते हैं जो उन्हें पास होने देता है।
उच्च-स्तरीय BDD के भीतर, हम पहले परिदृश्य लिखते हैं, फिर उन्हें पास करते हैं।
आपको बसने और पाने वाले को बाहर क्यों करना चाहिए?
सिद्धांत रूप में, टीडीडी के भीतर एक व्यक्ति के लिए परीक्षण लिखना पूरी तरह से संभव है, और एक और कोड को लागू करने के लिए जो इसे पास करता है।
इसलिए खुद से पूछें:
क्या क्लास लिखने वाले व्यक्ति को गेटर्स और सेटर का उल्लेख करना चाहिए।
चूँकि गेटर्स और सेटर एक वर्ग के लिए एक सार्वजनिक इंटरफ़ेस हैं, इसलिए उत्तर स्पष्ट रूप से हाँ है , या किसी वस्तु की स्थिति को सेट या क्वेरी करने का कोई तरीका नहीं होगा।
जाहिर है, यदि आप पहले कोड लिखते हैं, तो उत्तर इतना स्पष्ट नहीं हो सकता है।
अपवाद
इस नियम के कुछ स्पष्ट अपवाद हैं - ऐसे कार्य जो स्पष्ट रूप से कार्यान्वयन विस्तार हैं और स्पष्ट रूप से सिस्टम के डिजाइन का हिस्सा नहीं हैं।
उदाहरण के लिए, एक स्थानीय विधि 'बी ()':
function A() {
// B() will be called here
function B() {
...
}
}
या square()यहाँ निजी समारोह :
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
या कोई अन्य फ़ंक्शन जो publicइंटरफ़ेस का हिस्सा नहीं है जिसे सिस्टम घटक के डिज़ाइन में वर्तनी की आवश्यकता होती है।