शून्य से Go परीक्षण: नौसिखिए डेवलपर के लिए गाइड

Go में परीक्षण क्यों डरावना नहीं, बल्कि आवश्यक है

जब आप पहली बार Go में लिखते हैं, तो ऐसा लगता है कि कंपाइलर लगभग सब कुछ पकड़ लेता है: प्रकार सख्त हैं, त्रुटियाँ स्पष्ट हैं, nil नियंत्रण में है। लेकिन जैसे ही आपका प्रोजेक्ट 500+ लाइनों तक बढ़ता है, आप समझ जाते हैं: परीक्षणों के बिना रहना असंभव है। एक जगह एक बदलाव दूसरी जगह को तोड़ देता है, और आपको इसके बारे में प्रोडक्शन में ही पता चलता है।

इस लेख में मैं दिखाऊंगा कि नौसिखिए डेवलपर को Go में परीक्षण कहाँ से शुरू करना चाहिए। हम यूनिट टेस्ट, टेबल टेस्ट, मॉक और कोड कवरेज को समझेंगे। कोई बेकार की बात नहीं - केवल काम के उदाहरण और व्यावहारिक सुझाव।

यदि आप कम से कम कुछ महीनों से Go में लिख रहे हैं, तो यह सामग्री आपको डिबगिंग के घंटे बचाएगी।

शुरू करने से पहले क्या जानना चाहिए

Go एक अंतर्निहित पैकेज testing प्रदान करता है - कुछ भी अतिरिक्त स्थापित करने की आवश्यकता नहीं है। परीक्षण _test.go प्रत्यय वाली फ़ाइलों में लिखे जाते हैं और कमांड से चलाए जाते हैं:

go test ./...

मुख्य नियम:

\n
• परीक्षण फ़ंक्शन का नाम TestXxx(t *testing.T) होना चाहिए, जहाँ Xxx परीक्षण किए जा रहे फ़ंक्शन का नाम बड़े अक्षर से शुरू होता है।
\n
• परीक्षण फ़ाइलें परीक्षण किए जा रहे कोड के साथ ही होती हैं।
\n
• त्रुटियाँ t.Error() या t.Fatal() के माध्यम से बताई जाती हैं।
\n

चलिए सीधे अभ्यास पर आते हैं।

Go में पहला यूनिट टेस्ट लिखना

मान लीजिए, हमारे पास एक सरल फ़ंक्शन है जो दो संख्याओं को जोड़ता है:

// calc.go\npackage calc\n\nfunc Sum(a, b int) int {\n    return a + b\n}

उसी फ़ोल्डर में calc_test.go फ़ाइल बनाएँ:

// calc_test.go\npackage calc\n\nimport "testing"\n\nfunc TestSum(t *testing.T) {\n    result := Sum(2, 3)\n    expected := 5\n\n    if result != expected {\n        t.Errorf("Sum(2,3) = %d; want %d", result, expected)\n    }\n}

परीक्षण चलाएँ:

go test -v

आप हरा PASS देखेंगे - आपकी पहली परीक्षण जीत। ध्यान दें: हम t.Errorf (गैर-घातक) का उपयोग कर रहे हैं - भले ही एक मामला विफल हो, परीक्षण जारी रहेगा।

टेबल टेस्ट: जब एक परीक्षण असुविधाजनक हो

कल्पना करें कि आपको दर्जनों अलग-अलग इनपुट डेटा के साथ एक फ़ंक्शन का परीक्षण करना है। क्या 10 अलग-अलग परीक्षण लिखें? नहीं, Go में इसके लिए टेबल टेस्ट (table-driven tests) हैं। यह Go समुदाय के लिए मानक है।

अपने calc.go में विभाजन फ़ंक्शन जोड़ें:

func Divide(a, b int) (int, error) {\n    if b == 0 {\n        return 0, errors.New("division by zero")\n    }\n    return a / b, nil\n}

अब टेबल टेस्ट लिखें:

func TestDivide(t *testing.T) {\n    tests := []struct {\n        name     string\n        a, b     int\n        expected int\n        wantErr  bool\n    }{\n        {"positive", 10, 2, 5, false},\n        {"negative", -6, 3, -2, false},\n        {"zero division", 5, 0, 0, true},\n        {"same numbers", 7, 7, 1, false},\n    }\n\n    for _, tt := range tests {\n        t.Run(tt.name, func(t *testing.T) {\n            got, err := Divide(tt.a, tt.b)\n            if tt.wantErr {\n                if err == nil {\n                    t.Error("expected error, got nil")\n                }\n                return\n            }\n            if err != nil {\n                t.Errorf("unexpected error: %v", err)\n            }\n            if got != tt.expected {\n                t.Errorf("Divide(%d,%d) = %d; want %d", tt.a, tt.b, got, tt.expected)\n            }\n        })\n    }\n}

यहाँ क्या शानदार है:

\n
• प्रत्येक मामला नाम के साथ एक अलग उप-परीक्षण है। यदि एक विफल होता है, तो बाकी निष्पादित होंगे।
\n
• नए मामले जोड़ना आसान है - बस संरचना में एक पंक्ति जोड़ें।
\n
• कोड एक विनिर्देश की तरह पढ़ा जाता है।
\n

-v फ्लैग के साथ चलाएँ - आप सभी उप-परीक्षणों के नाम देखेंगे। डिबगिंग के दौरान यह बहुत सुविधाजनक है।

परीक्षण