TDD Java में शुरुआत से: टेस्ट कैसे कोड बदलते हैं और नसें बचाते हैं

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

TDD सिर्फ 'टेस्ट लिखना' नहीं, बल्कि 'अलग तरह से सोचना' है

\n\n

कल्पना करें कि आप एक घर बना रहे हैं। आपके पास ब्लूप्रिंट, सामग्री और एक टीम है। लेकिन आप नींव की जाँच किए बिना ईंटें रखना शुरू कर देते हैं। एक महीने बाद पता चलता है कि दीवारों में दरारें आ गई हैं। परिचित लग रहा है? प्रोग्रामिंग में इसे 'बाद में ठीक करेंगे' कहा जाता है। और 'बाद में' आमतौर पर डिप्लॉयमेंट से पहले रात के 3 बजे आता है।

\n\n

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

\n\n

इस लेख में, हम ठोस उदाहरणों के साथ Java में TDD को समझेंगे। कोई बकवास नहीं - केवल कोड, Red-Green-Refactor चक्र और वास्तविक परिदृश्य। चलिए शुरू करते हैं।

\n\n

TDD क्या है और Red-Green-Refactor चक्र कैसे काम करता है

\n\n

TDD तीन सरल चरणों पर आधारित है जो चक्रीय रूप से दोहराए जाते हैं:

\n\n

Red - हम एक टेस्ट लिखते हैं जो पास नहीं होता (इसे फेल होना चाहिए)।
Green - हम न्यूनतम कोड लिखते हैं ताकि टेस्ट पास हो जाए।
Refactor - हम कोड को बेहतर बनाते हैं, उसके व्यवहार को बदले बिना। टेस्ट इस दौरान हरे (पास) रहते हैं।

\n\n

ऐसा लगता है कि इससे डेवलपमेंट धीमा हो जाता है। वास्तव में, यह इसे तेज करता है। आप यह अनुमान लगाना बंद कर देते हैं कि 'क्या यह काम कर रहा है?'। आप जानते हैं: यह काम कर रहा है, क्योंकि टेस्ट हरा है।

\n\n

TDD के मुख्य सिद्धांत

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

\n\n

अब चलिए Java और JUnit 5 की ओर बढ़ते हैं - यूनिट टेस्टिंग के लिए सबसे लोकप्रिय फ्रेमवर्क।

\n\n

प्रोजेक्ट सेटअप: Maven, JUnit 5 और स्ट्रक्चर

\n\n

उदाहरणों के लिए हम Maven का उपयोग करेंगे। pom.xml में यह डिपेंडेंसी जोड़ें:

\n\n

<dependency>\n    <groupId>org.junit.jupiter</groupId>\n    <artifactId>junit-jupiter-api</artifactId>\n    <version>5.10.0</version>\n    <scope>test</scope>\n</dependency>

\n\n

Maven के लिए फ़ोल्डर संरचना मानक है:

src/\n  main/java/com/example/\n  test/java/com/example/

\n\n

सभी टेस्ट क्लासेज को src/test/java में रखें। टेस्ट क्लास का नाम आमतौर पर टेस्ट किए जा रहे क्लास के नाम से मेल खाता है और इसमें Test प्रत्यय जोड़ा जाता है। उदाहरण के लिए, Calculator → CalculatorTest।

\n\n

पहला TDD चक्र: शुरुआत से कैलकुलेटर बनाना

\n\n

कार्य: एक add(int a, int b) मेथड बनाना जो योग लौटाता है। TDD के अनुसार, हम क्लास से नहीं, बल्कि टेस्ट से शुरू करते हैं।

\n\n

चरण 1: Red - एक टेस्ट लिखें जो फेल होगा

\n\n

import org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.*;\n\npublic class CalculatorTest {\n\n    @Test\n    void shouldAddTwoNumbers() {\n        Calculator calc = new Calculator();\n        int result = calc.add(2, 3);\n        assertEquals(5, result);\n    }\n}

\n\n

इसे चलाने की कोशिश करें - कंपाइलर त्रुटि देगा: Calculator क्लास मौजूद नहीं है। बढ़िया, लाल बत्ती जल गई।

\n\n

चरण 2: Green - न्यूनतम कोड लिखें

\n\n

Calculator क्लास बनाएं जिसमें एक मेथड हो जो सिर्फ योग लौटाता है:

\n\n

public class Calculator {\n    public int add(int a, int b) {\n        return a + b;\n    }\n}

\n\n

टेस्ट चलाएं - हरा। न्यूनतम संभव कार्यान्वयन ने काम किया।

\n\n

चरण 3: Refactor

\n\n

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