Rust में परीक्षण: unit, integration, e2e शुरू से अंत तक

परिचय: Rust में परीक्षण क्यों सिर्फ फैशनेबल नहीं, बल्कि आवश्यक है

Rust एक ऐसी भाषा है जो अपनी मेमोरी सुरक्षा और उच्च प्रदर्शन के लिए प्रसिद्ध है। हालांकि, सबसे सख्त कंपाइलर भी व्यावसायिक तर्क की शुद्धता की गारंटी नहीं देता है। यहीं पर परीक्षण मंच पर आता है। Rust में, प्रकार और स्वामित्व प्रणाली पहले से ही संकलन चरण में त्रुटियों के एक पूरे वर्ग को समाप्त कर देती है, लेकिन मॉड्यूलर, इंटीग्रेशन और एंड-टू-एंड (e2e) परीक्षण यह सुनिश्चित करने में मदद करते हैं कि आपका कोड वही करता है जो आपने सोचा था।

इस लेख में, हम Rust में परीक्षण के तीन स्तरों का विश्लेषण करेंगे: पृथक unit-परीक्षणों से लेकर पूर्ण e2e-परिदृश्यों तक। आप सीखेंगे कि प्रभावी परीक्षण कैसे लिखें, किन उपकरणों का उपयोग करें और परीक्षण बुनियादी ढांचे को कैसे व्यवस्थित करें। यह सामग्री उन नौसिखियों के लिए उपयोगी होगी जो अभी Rust सीखना शुरू कर रहे हैं, साथ ही अनुभवी डेवलपर्स के लिए जो अपने ज्ञान को व्यवस्थित करना चाहते हैं।

1. Unit-परीक्षण: आधार की नींव

Unit-परीक्षण (मॉड्यूलर परीक्षण) सबसे तेज़ और सबसे पृथक सत्यापन स्तर है। वे बाहरी निर्भरताओं से अलग होकर अलग-अलग फ़ंक्शन, विधियों या छोटे मॉड्यूल का परीक्षण करते हैं। Rust में, unit-परीक्षणों को उसी फ़ाइल में रखने की प्रथा है जहाँ परीक्षण किया जा रहा कोड है, tests मॉड्यूल के अंदर।

1.1. संरचना और विशेषताएँ

unit-परीक्षण बनाने के लिए #[test] विशेषता का उपयोग किया जाता है। इससे चिह्नित फ़ंक्शन कोई तर्क नहीं लेता है और कुछ भी वापस नहीं करता है (या Result लौटाता है)। यदि फ़ंक्शन के अंदर पैनिक (panic) होता है, तो परीक्षण विफल माना जाता है।

// src/lib.rs\npub fn add(a: i32, b: i32) -> i32 {\n    a + b\n}\n\n#[cfg(test)]\nmod tests {\n    use super::*;\n\n    #[test]\n    fn test_add() {\n        assert_eq!(add(2, 2), 4);\n    }\n\n    #[test]\n    fn test_add_negative() {\n        assert_eq!(add(-1, -1), -2);\n    }\n}

#[cfg(test)] पर ध्यान दें। यह विशेषता सुनिश्चित करती है कि परीक्षणों वाला मॉड्यूल केवल परीक्षण चलाने पर ही संकलित होगा (cargo test)। यह production बिल्ड में शामिल नहीं होगा।

1.2. जाँच के लिए मैक्रोज़

Rust अभिकथनों की जाँच के लिए कई मैक्रोज़ प्रदान करता है:

\n
• assert!(expr) — जाँचता है कि अभिव्यक्ति सत्य है।
\n
• assert_eq!(left, right) — समानता की जाँच करता है (PartialEq और Debug की आवश्यकता है)।
\n
• assert_ne!(left, right) — असमानता की जाँच करता है।
\n
• panic!("message") — जबरन पैनिक उत्पन्न करता है (त्रुटियों के परीक्षण के लिए उपयोग किया जाता है)।
\n

1.3. should_panic के साथ पैनिक का परीक्षण

यदि आपका फ़ंक्शन गलत इनपुट डेटा पर पैनिक करना चाहिए, तो #[should_panic] विशेषता का उपयोग करें:

pub fn divide(a: f64, b: f64) -> f64 {\n    if b == 0.0 {\n        panic!("Division by zero");\n    }\n    a / b\n}\n\n#[cfg(test)]\nmod tests {\n    use super::*;\n\n    #[test]\n    #[should_panic(expected = "Division by zero")]\n    fn test_divide_by_zero() {\n        divide(10.0, 0.0);\n    }\n}

expected पैरामीटर अनिवार्य नहीं है, लेकिन यह परीक्षण को अधिक सटीक बनाता है: पैनिक में निर्दिष्ट स्ट्रिंग होनी चाहिए।

2. इंटीग्रेशन परीक्षण: मॉड्यूल के बीच इंटरैक्शन की जाँच

इंटीग्रेशन परीक्षण जाँचते हैं कि आपके एप्लिकेशन के विभिन्न भाग एक साथ कैसे काम करते हैं। unit-परीक्षणों के विपरीत, वे प्रोजेक्ट रूट स्तर पर tests/ निर्देशिका में स्थित होते हैं (src/ के बगल में)। इस फ़ोल्डर में प्रत्येक फ़ाइल एक अलग क्रेट-लाइब्रेरी के रूप में संकलित होती है।

2.1. इंटीग्रेशन परीक्षण बनाना

एक फ़ाइल tests/integration_test.rs बनाएँ:

// tests/integration_test.rs\nuse my_crate::add; // मान लें कि आपका क्रेट my_crate कहलाता है\n\n#[test]\nfn test_add_integration() {\n    let result = add(5, 10);\n    assert_eq!(result, 15);\n}

केवल इंटीग्रेशन परीक्षण चलाने के लिए