TDD in C#: परीक्षणों से डरना छोड़ें और ऐसा कोड लिखना शुरू करें जो दिखाने में शर्म न आए

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

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

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

क्यों "पहले परीक्षण" आत्म-पीड़न नहीं, बल्कि एक महाशक्ति है

\n\n

कल्पना करें: आप कोड लिख रहे हैं, सब कुछ काम कर रहा है। आप खुश हैं। एक महीने बाद आप प्रोजेक्ट पर वापस आते हैं, एक लाइन बदलते हैं — और सब कुछ टूट जाता है। परिचित लगता है? उन डेवलपर्स के क्लब में आपका स्वागत है जो परीक्षण नहीं लिखते। अब एक और वास्तविकता की कल्पना करें: आप कोड बदलते हैं, परीक्षण चलाते हैं — और 10 सेकंड में जान जाते हैं कि कुछ भी नहीं टूटा। यह जादू नहीं है, यह TDD (Test-Driven Development) है — परीक्षण-संचालित विकास।

\n\n

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

\n\n

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

\n\n

TDD परीक्षण के बारे में नहीं है। यह डिज़ाइन के बारे में है। आप कोड के बाद परीक्षण नहीं लिखते, बल्कि इसके विपरीत: पहले परीक्षण, फिर न्यूनतम कोड जो उसे पास करे, और उसके बाद ही रिफैक्टरिंग। इस चक्र को Red-Green-Refactor कहा जाता है:

\n\n

Red — हम एक परीक्षण लिखते हैं जो जानबूझकर विफल होगा (लाल)।
Green — हम न्यूनतम कोड लिखते हैं ताकि परीक्षण पास हो (हरा)।
Refactor — हम कोड में सुधार करते हैं, उसके व्यवहार को बदले बिना।

\n\n

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

\n\n

चरण 1: Red — एक परीक्षण लिखें जो विफल होगा

\n\n

using NUnit.Framework;\n\n[TestFixture]\npublic class CalculatorTests\n{\n    [Test]\n    public void Add_ShouldReturnSumOfTwoNumbers()\n    {\n        // Arrange\n        var calculator = new Calculator();\n        \n        // Act\n        var result = calculator.Add(2, 3);\n        \n        // Assert\n        Assert.AreEqual(5, result);\n    }\n}

\n\n

चलाएँ — परीक्षण विफल होता है, क्योंकि Calculator क्लास मौजूद नहीं है। लाल — यह सामान्य है। अब हमारा काम हरा बनाना है।

\n\n

चरण 2: Green — परीक्षण पास करने के लिए न्यूनतम कोड

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        return a + b; // न्यूनतम कार्यान्वयन\n    }\n}

\n\n

परीक्षण हरा है। वाह। लेकिन कोड अभी बदसूरत है। चरण 3 पर चलते हैं।

\n\n

चरण 3: Refactor — सुधारें, लेकिन तोड़ें नहीं

\n\n

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

\n\n

public class Calculator\n{\n    public int Add(int a, int b)\n    {\n        if (a < 0 || b < 0)\n            throw new ArgumentException("Only positive numbers allowed");\n        return a + b;\n    }\n}

\n\n

परीक्षण विफल होगा? हाँ। तो, परीक्षण को अपडेट करना या तर्क बदलना होगा। TDD में रिफैक्टरिंग हमेशा परीक्षणों के साथ एक संवाद है।

\n\n