🧪 यूनिट टेस्टिंग: Go में कमांड्स बनाम मॉक्स (Commands vs Mocks) 🔗

Go में यूनिट टेस्ट लिखते समय, फ़ाइल सिस्टम, सिस्टम क्लॉक या बाहरी कमांड जैसी बाहरी निर्भरताओं (external dependencies) को संभालना पेचीदा हो सकता है। यह पोस्ट इससे निपटने के तीन तरीकों की पड़ताल करती है, और अंततः यह दिखाती है कि क्यों कमांड पैटर्न (Command Pattern) जटिल मॉक्स (mocks) की तुलना में एक साफ-सुथरा और आसानी से टेस्ट किया जा सकने वाला विकल्प प्रदान करता है।

आइए एक उदाहरण देखें: इंक्रीमेंटल बिल्ड (incremental builds) को बेंचमार्क करने के लिए डिज़ाइन किया गया एक फ़ंक्शन।

func Benchmark(binary string, sourcePath string, resultPath string, numBuilds int) error {
	if err := build(binary); err != nil {
		return err
	}
	source, err := read(sourcePath)
	if err != nil {
		return err
	}
	
	deltas := []time.Duration{}
	for i := 0; i < numBuilds; i++ {
		if err := write(sourcePath, edit(source, i)); err != nil {
			return err
		}
		
		start := now()
		if err := build(binary); err != nil {
			return err
		}
		
		delta := now().Sub(start)
		deltas = append(deltas, delta)
		
		if err := revert(sourcePath); err != nil {
			return err
		}
	}
	return write(resultPath, report(deltas))
}

📑 विषय-सूची 🔗

⚠️ समस्या 🔗

यह Benchmark फ़ंक्शन कई काम करता है:

1. एक बाइनरी बिल्ड करता है।
2. एक सोर्स फ़ाइल पढ़ता है।
3. सोर्स को एडिट करने, बिल्ड समय मापने और फ़ाइल को वापस पहले जैसा (revert) करने के लिए लूप चलाता है।
4. अंतिम रिपोर्ट लिखता है।

इसे सीधे टेस्ट करना कठिन है क्योंकि यह चार बाहरी निर्भरताओं पर आधारित है:

• कंपाइलर (Compiler): build()
• फ़ाइल सिस्टम (File System): read() और write()
• सिस्टम क्लॉक (System Clock): now()
• वर्ज़न कंट्रोल (Version Control): revert()

कई डेवलपर्स केवल स्वतंत्र edit और report फ़ंक्शंस को ही टेस्ट कर पाते हैं, जिससे मुख्य ऑर्केस्ट्रेशन (समन्वय) बिना टेस्ट किए रह जाता है। यहाँ बताया गया है कि हम पूरी प्रक्रिया को टेस्ट करने योग्य बनाने के लिए डिज़ाइन में कैसे सुधार कर सकते हैं।

1️⃣ तरीका 1: कोड को Main में ले जाएँ 🔗

कभी-कभी, आप निर्भरताओं को कॉलर (अक्सर main) के स्तर पर ऊपर धकेल सकते हैं।

func Benchmark(binary string, sourcePath string, source string, numBuilds int) (string, error) {
	// ... core loop logic remains ...
	// returning the report string instead of writing it
	return report(deltas), nil
}

func Main() error {
	// setup and initial build moved here
	source, _ := read(sourcePath)
	result, _ := Benchmark(binary, sourcePath, source, 3)
	return write(resultPath, result)
}

निर्णय: हालांकि इससे मदद मिलती है, लेकिन यहाँ यह पर्याप्त नहीं है। Benchmark लूप को अभी भी हर चरण के दौरान बिल्ड सिस्टम, क्लॉक, फ़ाइल सिस्टम और वर्ज़न कंट्रोल के साथ बुनियादी रूप से इंटरैक्ट करने की आवश्यकता होती है।

2️⃣ तरीका 2: डिपेंडेंसी इंजेक्शन (Mocks/Fakes) 🔗

पारंपरिक ऑब्जेक्ट-ओरिएंटेड तरीका डिपेंडेंसी इंजेक्शन (Dependency Injection) है। आप सभी बाहरी कार्यों का प्रतिनिधित्व करने वाला एक इंटरफ़ेस परिभाषित करते हैं।

type Delegate interface {
	Build(binary string) error
	Read(path string) (string, error)
	Write(path string, content string) error
	Now() time.Time
	Revert(path string) error
}

type BenchmarkRunner struct {
	Delegate Delegate
}

func (b *BenchmarkRunner) Run(binary string, sourcePath string, resultPath string, numBuilds int) error {
	// ... implementation using b.Delegate.Build(), b.Delegate.Now(), etc ...
}

निर्णय: यह अच्छी तरह से काम करता है और आपको टेस्टिंग के लिए एक नकली (fake) डेलीगेट बदलने की अनुमति देता है। हालांकि, इसके लिए हर प्रकार के साइड इफ़ेक्ट के लिए इंटरफ़ेस और मॉक इम्प्लीमेंटेशन परिभाषित करने की आवश्यकता होती है, जिससे इंटरफ़ेस अनावश्यक रूप से बड़े और जटिल (bloat) हो सकते हैं।

3️⃣ तरीका 3: कमांड पैटर्न (The Command Pattern) 🔗

हर कार्य के लिए विशिष्ट इंटरफ़ेस परिभाषित करने के बजाय, हम प्रत्येक साइड इफ़ेक्ट को एक केंद्रीय “Runner” द्वारा निष्पादित किए जाने वाले एक सामान्य कमांड (generic command) के रूप में मान सकते हैं।

सबसे पहले, परिभाषित करें कि कमांड चलाने का क्या अर्थ है:

type Runner interface {
	Run(cmd Command) (Result, error)
}

इसके बाद, अपने विशिष्ट कमांड्स को सरल स्ट्रक्ट्स (या स्थिरांक) के रूप में परिभाषित करें:

type BuildCmd struct { Binary string }
type ReadCmd struct { Path string }
type WriteCmd struct { Path string; Content string }
type NowCmd struct {}
type RevertCmd struct { Path string }

अब, बेंचमार्क लॉजिक को इस तरह रीफ़ैक्टर करें कि वह उन कमांड्स को लौटाए जिन्हें वह चलाना चाहता है, या नियंत्रण किसी रनर को सौंप दे:

type BenchmarkProcess struct {
	runner Runner
}

func (p *BenchmarkProcess) Execute(binary, sourcePath, resultPath string, numBuilds int) error {
	_, err := p.runner.Run(BuildCmd{Binary: binary})
	if err != nil { return err }
	
	readRes, err := p.runner.Run(ReadCmd{Path: sourcePath})
	if err != nil { return err }
	source := readRes.(string) // Type assertion needed here

	// ... rest of the loop using p.runner.Run() ...
}

💡 टेस्टिंग के लिए कमांड्स बेहतर क्यों हैं 🔗

इस पैटर्न की असली ताकत यूनिट टेस्ट में चमकती है। आपको हर निर्भरता के लिए जटिल मॉक इंटरफ़ेस लागू करने के बजाय केवल एक FakeRunner लिखने की आवश्यकता होती है।

टेस्ट अपेक्षित कमांड्स और मॉक किए गए उत्तरों की एक सरल सूची बन जाता है:

func TestBenchmark(t *testing.T) {
	// 1. Define the script: "When you see this command, return this result"
	fakeRunner := NewFakeRunner([]Step{
		{Cmd: BuildCmd{"binary"}, Err: nil},
		{Cmd: ReadCmd{"source_path"}, Res: "source code", Err: nil},
		{Cmd: WriteCmd{"source_path", "edited code"}, Err: nil},
		{Cmd: NowCmd{}, Res: time.Unix(0, 0), Err: nil},
		// ... and so on ...
	})

	p := BenchmarkProcess{runner: fakeRunner}
	err := p.Execute("binary", "source_path", "result_path", 1)
	
	if err != nil {
		t.Fatalf("unexpected error: %v", err)
	}
	
	// 2. Verify the runner consumed all expected steps
	if !fakeRunner.IsDone() {
		t.Fatalf("did not execute all expected commands")
	}
}

🎯 सारांश 🔗

फ़ंक्शन कॉल्स को डेटा स्ट्रक्चर्स (Commands) में बदलकर, आप अपने बिज़नेस लॉजिक को उसके साइड इफ़ेक्ट्स से अलग (decouple) कर देते हैं।

• Mocks/DI: बड़ी और अलग-अलग सेवाओं को आपस में बदलने के लिए अच्छे हैं।
• Commands: अत्यधिक समन्वित (orchestrated) लॉजिक के लिए उत्कृष्ट हैं जहाँ आप उबाऊ बॉयलरप्लेट मॉक्स लिखे बिना ऑपरेशनों के सटीक अनुक्रम (exact sequence) की पुष्टि करना चाहते हैं।