टीडीडी का उपयोग करने का एक सरल लेकिन निराशाजनक उदाहरण

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

मैं सिद्धांत का वर्णन नहीं करूंगा, इसे आसानी से स्वतंत्र रूप से पाया जा सकता है। उदाहरण जावा में लिखा गया है, TestNG का उपयोग यूनिट-टेस्ट फ्रेमवर्क के रूप में किया जाता है।

कार्य

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

ऐसा लगता है कि यह सरल हो सकता है:

public class Unit { private int health; private int damage; public int getHealth() { return health; } public int setHealth(int health) { this.health = health; } public int getDamage() { return damage; } public int setDamage(int damage) { this.damage = damage; } } 

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

तो, यह वही है जो पारंपरिक "माथे" विधि है। अब टीडीडी के माध्यम से उसी वर्ग को लागू करने का प्रयास करते हैं।

TDD लागू करें

वास्तव में, मैंने उपरोक्त कार्यान्वयन नहीं लिखा था, शुरू में कोई इकाई वर्ग मौजूद नहीं था। हम टेस्ट क्लास बनाकर शुरू करते हैं।

 @Test public class UnitTest { } 

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

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } } 

परीक्षण, ज़ाहिर है, संकलन भी नहीं करता है - हम ऐसा करते हैं ताकि यह गुजर जाए।

 public class Unit { public Unit(int health, int damage) { } } 

अभी तक रिफ्लेक्टर के लिए कुछ भी नहीं है। हम अगला परीक्षण लिख रहे हैं - मैं इकाई के वर्तमान स्वास्थ्य का पता लगाना चाहता हूं।

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } @Test public void youCheckUnitHealthWithGetter() { Unit unit = new Unit(100, 25); assertEquals(100, unit.getHealth()); } } 

संकलन त्रुटि के कारण परीक्षण क्रैश हो जाता है - यूनिट वर्ग के पास एक गेटलिथ विधि नहीं है। हम कोड को सही करते हैं ताकि परीक्षण पास हो जाए।

 public class Unit { private int health; public Unit(int health, int damage) { this.health = health; } public int getHealth() { return health; } } 

फिर से रिफ्लेक्टर करने के लिए कुछ भी नहीं है। हम आगे सोचते हैं - यूनिट को नुकसान उठाने में सक्षम होना शायद अच्छा होगा।

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } @Test public void youCheckUnitHealthWithGetter() { Unit unit = new Unit(100, 25); assertEquals(100, unit.getHealth()); } @Test public void unitCanTakeDamage() { Unit unit = new Unit(100, 25); unit.takeDamage(25); } } 

हम कोड को सही करते हैं ताकि परीक्षण पास हो जाए।

 public class Unit { private int health; public Unit(int health, int damage) { this.health = health; } public int getHealth() { return health; } public void takeDamage(int damage) { } } 

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

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } @Test public void youCheckUnitHealthWithGetter() { Unit unit = new Unit(100, 25); assertEquals(100, unit.getHealth()); } @Test public void unitCanTakeDamage() { Unit unit = new Unit(100, 25); unit.takeDamage(25); } @Test public void damageTakenReducesUnitHealth() { Unit unit = new Unit(100, 25); unit.takeDamage(25); assertEquals(75, unit.getHealth()); } } 

पहला परीक्षण जो वर्ग व्यवहार के कारण दुर्घटनाग्रस्त होता है। अधिकार।

 public class Unit { private int health; public Unit(int health, int damage) { this.health = health; } public int getHealth() { return health; } public void takeDamage(int damage) { health -= damage; } } 

यहां आप पहले से ही थोड़ा रिफ्लेक्टर कर सकते हैं। यहां आप इसे ऐसे ही छोड़ सकते हैं, लेकिन मुझे क्लास के अंत में गेटर्स का उपयोग किया जाता है।

 public class Unit { private int health; public Unit(int health, int damage) { this.health = health; } public void takeDamage(int damage) { health -= damage; } public int getHealth() { return health; } } 

हम आगे बढ़ते हैं। हमारी इकाई में पहले से ही एक स्वास्थ्य आरक्षित है और क्षतिग्रस्त हो सकता है। हम उसे सिखाएंगे कि अन्य इकाइयों को कैसे नुकसान पहुँचाया जाए!

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } @Test public void youCheckUnitHealthWithGetter() { Unit unit = new Unit(100, 25); assertEquals(100, unit.getHealth()); } @Test public void unitCanTakeDamage() { Unit unit = new Unit(100, 25); unit.takeDamage(25); } @Test public void damageTakenReducesUnitHealth() { Unit unit = new Unit(100, 25); unit.takeDamage(25); assertEquals(75, unit.getHealth()); } @Test public void unitCanDealDamageToAnotherUnit() { Unit damageDealer = new Unit(100, 25); Unit damageTaker = new Unit(100, 25); damageDealer.dealDamage(damageTaker); } } 

हम यूनिट क्लास को अंतिम रूप दे रहे हैं।

 public class Unit { private int health; public Unit(int health, int damage) { this.health = health; } public void takeDamage(int damage) { health -= damage; } public void dealDamage(Unit damageTaker) { } public int getHealth() { return health; } } 

यह स्पष्ट है कि यदि हमारी इकाई ने किसी अन्य इकाई को नुकसान पहुंचाया है, तो किसी के स्वास्थ्य में कमी आ सकती है।

 @Test public class UnitTest { @Test public void youCreateAUnitGivenItsHealthAndDamage() { new Unit(100, 25); } @Test public void youCheckUnitHealthWithGetter() { Unit unit = new Unit(100, 25); assertEquals(100, unit.getHealth()); } @Test public void unitCanTakeDamage() { Unit unit = new Unit(100, 25); unit.takeDamage(25); } @Test public void damageTakenReducesUnitHealth() { Unit unit = new Unit(100, 25); unit.takeDamage(25); assertEquals(75, unit.getHealth()); } @Test public void unitCanDealDamageToAnotherUnit() { Unit damageDealer = new Unit(100, 25); Unit damageTaker = new Unit(100, 25); damageDealer.dealDamage(damageTaker); } @Test public void unitThatDamageDealtToTakesDamageDealerUnitDamage() { Unit damageDealer = new Unit(100, 25); Unit damageTaker = new Unit(100, 25); damageDealer.dealDamage(damageTaker); assertEquals(75, damageTaker.getHealth()); } } 

ताजा लिखित परीक्षा में गिरावट होती है - हम इकाई वर्ग को ठीक कर देंगे।

 public class Unit { private int health; private int damage; public Unit(int health, int damage) { this.health = health; this.damage = damage; } public void takeDamage(int damage) { health -= damage; } public void dealDamage(Unit damageTaker) { damageTaker.takeDamage(damage); } public int getHealth() { return health; } } 

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

 public class Unit { private int health; private final int damage; public Unit(int health, int damage) { this.health = health; this.damage = damage; } public void takeDamage(int incomingDamage) { health -= incomingDamage; } public void dealDamage(Unit damageTaker) { damageTaker.takeDamage(damage); } public int getHealth() { return health; } } 

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

निष्कर्ष

1. "हेड-ऑन" को लागू करने की तुलना में सबसे सरल वर्ग को लागू करने में कई बार अधिक समय लगा - यह वही है जो टीडीडी में प्रबंधकों और गैर-तकनीकी प्रोग्रामर को इतनी बार डराता है।
   
2. आप पहले भोले कार्यान्वयन और पिछले प्राप्त TDD के माध्यम से तुलना कर सकते हैं। मुख्य अंतर यह है कि अंतिम कार्यान्वयन वास्तव में ऑब्जेक्ट-ओरिएंटेड है, आप एक स्वतंत्र ऑब्जेक्ट के रूप में यूनिट के साथ काम कर सकते हैं, इसकी स्थिति के बारे में पूछ सकते हैं और कुछ कार्यों को करने के लिए कह सकते हैं। इस वर्ग के साथ काम करने वाला कोड भी अधिक ऑब्जेक्ट ओरिएंटेड होगा।
   
3. कक्षा के अलावा, हमें इसके लिए परीक्षणों का एक पूरा सेट मिला। मुझे अपने स्वयं के अनुभव से पता है कि किसी डेवलपर के लिए परीक्षणों द्वारा पूरी तरह से कवर किए गए कोड से अधिक लाभ की कल्पना करना कठिन है। उसी अनुभव से, यदि कोड के बाद परीक्षण लिखे गए हैं, तो पूर्ण कवरेज प्रदान करना मुश्किल हो सकता है - वे किसी चीज़ के लिए परीक्षण लिखना भूल जाएंगे, कुछ परीक्षण करने के लिए बहुत सरल लगेगा, आदि। परीक्षण स्वयं अक्सर जटिल और बोझिल होते हैं, क्योंकि एक परीक्षण परीक्षण कोड के कई पहलुओं का परीक्षण करने के लिए आकर्षक है। यहां हमें सरल, आसानी से समझने वाले परीक्षणों का एक सेट मिला, जिसे बनाए रखना बहुत आसान होगा।
   
4. हमें लाइव कोड प्रलेखन मिला! किसी को भी लेखक के विचार, उद्देश्य और वर्ग व्यवहार को समझने के लिए परीक्षण में विधियों के नाम पढ़ने की आवश्यकता है। कोड को समझना, यह जानकारी होना, परिमाण का एक क्रम आसान होगा और सहयोगियों को विचलित करने की कोई आवश्यकता नहीं है कि क्या समझा जाए।
   
5. पूर्ववर्ती पैराग्राफ पहले से ही अच्छी तरह से ज्ञात हैं, लेकिन मैंने अपने लिए एक नया निष्कर्ष बनाया है - जब टीडीडी के माध्यम से विकसित हो रहा है, तो मुझे लगता है कि मैं कक्षा से प्राप्त करना चाहता हूं, इसके व्यवहार और उपयोग के मामलों में बहुत बेहतर है। पहले से विकसित घटकों की अच्छी समझ होने से अधिक जटिल लिखना आसान हो जाएगा।
   
6. इस उदाहरण के लिए प्रासंगिक नहीं है, लेकिन मैं यहां एक और बिंदु जोड़ना चाहता था। परीक्षणों के माध्यम से विकसित करते समय, आप कार्यों की जटिलता का अधिक पर्याप्त रूप से आकलन करते हैं - आप हमेशा जानते हैं कि क्या पहले से ही काम कर रहा है, क्या पूरा होना बाकी है। परीक्षणों के बिना, आपको अक्सर यह महसूस होता है कि सब कुछ पहले से ही लिखा हुआ है, लेकिन यह पता चला है कि डिबगिंग और संशोधन के लिए अभी भी महत्वपूर्ण मात्रा में समय की आवश्यकता है।
   

मैं समझता हूं कि उदाहरण बहुत ही सरल है और मैं आपसे इसमें गलती नहीं खोजने के लिए कहता हूं। विषय इस बारे में नहीं है कि दो क्षेत्रों की एक कक्षा कैसे लिखी जाए, लेकिन आप ऐसे प्राथमिक उदाहरण के साथ भी TDD के लाभों को देख सकते हैं।

ध्यान देने के लिए आप सभी का धन्यवाद। उन्नत प्रोग्रामिंग तकनीकों को जानें और अपने काम का आनंद लें!