शून्य टेस्ट से TDD तक: टेस्ट-ड्रिवन डेवलपमेंट के लिए एक व्यावहारिक मार्गदर्शिका

आप अपने द्वारा बनाए गए ऐप को लेकर उत्साहित हैं। बस एक समस्या है - आपके पास कोई टेस्ट नहीं है। आप इसे टेस्ट-ड्रिवन डेवलपमेंट का उपयोग करके लिखना चाहते थे, लेकिन आप नहीं जानते थे कि कहां से शुरू करें। तो आप अटक गए हैं। यहां से कहां जाएं? आप बिना टेस्ट वाले ऐप से, अपने ऐप्स को TDD का उपयोग करके लिखने तक कैसे पहुंचते हैं?

वह कोड टेस्ट करें जो आपके पास पहले से है

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

यह TDD नहीं है। लेकिन मौजूदा कोड का टेस्ट करना आपको TDD सीखने में मदद करेगा:

• आप एज केसेज और एरर कंडीशन्स के बारे में सोचने का अभ्यास करते हैं।

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

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

• आप अच्छी तरह से संरचित टेस्ट लिखने का अभ्यास करते हैं।

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

• आप उन चीजों की खोज करते हैं जो कोड को टेस्ट करना कठिन बनाती हैं।

  जैसे-जैसे आप अधिक टेस्ट लिखते हैं, आप यह महसूस करना शुरू कर देंगे कि आपके सिस्टम के कौन से क्षेत्र टेस्ट करने में सबसे कठिन होंगे। जब आप उन क्षेत्रों को नोटिस करते हैं, तो आप उन्हें रीफैक्टरिंग की आवश्यकता वाले स्थानों के रूप में हाइलाइट कर सकते हैं। इससे भी बेहतर, आप पहली बार अधिक टेस्टेबल कोड लिखना शुरू कर देंगे।

  एक बार जब आप जान जाते हैं कि आसानी से टेस्ट होने वाला कोड कैसा दिखता है, तो आप उस ज्ञान के साथ टेस्ट करने में आसान APIs को TDD कर सकते हैं। और यह आपको अपने ऐप्स को तेजी से बनाने में मदद करेगा।

TDD में सहजता से प्रवेश करें

आप TDD सीखने में मदद करने के लिए स्किल्स बनाने के लिए टेस्ट-आफ्टर का उपयोग कर सकते हैं। लेकिन आप अंततः अपने ऐप के टुकड़ों को TDD करना चाहते हैं। और TDD में सहजता से प्रवेश करने का एक सरल तरीका है, और फिर भी मौजूदा कोड पर भरोसा करना: रिग्रेशन टेस्ट लिखें।

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

• बग को पुन: पेश करने के लिए एक फेलिंग टेस्ट लिखें।
• टेस्ट चलाएं, और सुनिश्चित करें कि वे फेल होते हैं (क्योंकि वह बग अभी भी मौजूद है)।
• बग को ठीक करें सबसे सरल तरीके से संभव।
• टेस्ट चलाएं, और सुनिश्चित करें कि वे पास होते हैं।
• रीफैक्टर करें यदि आवश्यक हो।

यह स्क्रैच से एक नए सिस्टम को TDD करने की तुलना में बहुत आसान है, क्योंकि आप पहले से मौजूद कोड में केवल एक परिवर्तन को टेस्ट-ड्राइव कर रहे हैं। आप "रेड, ग्रीन, रीफैक्टर" की आदत बनाते हैं जो TDD का आवश्यक लूप है। और यहां से, TDD, बिना टेस्ट से सीधे TDD पर जाने की कोशिश करने की तुलना में एक छोटा कदम दूर है।

कुछ भी नहीं से TDD तक

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

तो, यदि आप नहीं जानते कि जिस सिस्टम की आप कल्पना कर रहे हैं उसे कैसे TDD करना है, तो टेस्ट लिखते रहें। भले ही आपको पहले कोड लिखना पड़े।