जंग (अनुवाद) में अंतर्निहित परीक्षण कार्यक्षमता के उपकरण के बारे में

नमस्कार, हेब्र! मैं जॉन रेनर के ब्लॉग पर "2018 में प्रवेश" # [परीक्षण] का अनुवाद आपके लिए प्रस्तुत करता हूं, जो यहां पाया जा सकता है ।

हाल ही में, मैं Rust के लिए कस्टम टेस्ट फ्रेमवर्क के लिए eRFC के कार्यान्वयन पर काम कर रहा हूं। संकलक के कोड आधार का अध्ययन करते हुए, मैंने रस्ट में परीक्षण के आंतरिक अध्ययन का अध्ययन किया और महसूस किया कि इसे साझा करना दिलचस्प होगा।

विशेषता # [परीक्षण]

आज, रस्ट प्रोग्रामर अंतर्निहित विशेषता #[test] पर भरोसा करते हैं। आपको बस इतना करना है कि फ़ंक्शन को परीक्षण के रूप में चिह्नित करें और कुछ चेक सक्षम करें:

 #[test] fn my_test() { assert!(2+2 == 4); } 

जब इस प्रोग्राम को rustc --test या cargo test कमांड का उपयोग करके संकलित किया जाता है, तो यह एक निष्पादन योग्य फ़ाइल बना देगा जो इसे और किसी भी अन्य परीक्षण फ़ंक्शन को चला सकता है। यह परीक्षण विधि आपको कोड के करीब परीक्षणों को व्यवस्थित रखने की अनुमति देती है। तुम भी निजी मॉड्यूल के अंदर परीक्षण डाल सकते हैं:

 mod my_priv_mod { fn my_priv_func() -> bool {} #[test] fn test_priv_func() { assert!(my_priv_func()); } } 

इस प्रकार, किसी भी बाहरी परीक्षण उपकरण का उपयोग किए बिना निजी संस्थाओं को आसानी से परीक्षण किया जा सकता है। यह जंग में एर्गोनोमिक परीक्षण की कुंजी है। शब्दार्थ, तथापि, यह बल्कि अजीब है। यदि वे दिखाई नहीं देते हैं तो main फ़ंक्शन इन परीक्षणों को कैसे बुलाता है ( अनुवादक का नोट : मैं आपको याद दिलाता हूं, निजी - pub कीवर्ड का उपयोग किए बिना घोषित - बाहरी पहुंच से एनकैप्सुलेशन द्वारा संरक्षित हैं)? वास्तव में rustc --test क्या करता है?

#[test] libsyntax संकलक libsyntax अंदर एक वाक्यविन्यास रूपांतरण के रूप #[test] लागू किया जाता है। यह अनिवार्य रूप से एक फैंसी मैक्रो है जो 3 चरणों में हमारे टोकरे को फिर से लिखता है:

चरण 1: फिर से निर्यात करें

जैसा कि पहले उल्लेख किया गया है, परीक्षण निजी मॉड्यूल के अंदर मौजूद हो सकते हैं, इसलिए हमें मौजूदा कोड को तोड़ने के बिना उन्हें main फ़ंक्शन को उजागर करने का एक तरीका चाहिए। इसके लिए, libsyntax स्थानीय मॉड्यूल बनाता है जिसे __test_reexports कहा जाता है जो __test_reexports : __test_reexports परीक्षण करता है । इस प्रकटीकरण में उपरोक्त उदाहरण का अनुवाद किया गया है:

 mod my_priv_mod { fn my_priv_func() -> bool {} fn test_priv_func() { assert!(my_priv_func()); } pub mod __test_reexports { pub use super::test_priv_func; } } 

अब हमारा परीक्षण my_priv_mod::__test_reexports::test_priv_func रूप में उपलब्ध है। नेस्टेड मॉड्यूल के लिए, __test_reexports परीक्षण वाले मॉड्यूल को __test_reexports करेगा, इसलिए परीक्षण a::b::my_test a::__test_reexports::b::__test_reexports::my_test । यह प्रक्रिया अब तक बहुत सुरक्षित लगती है, लेकिन मौजूदा __test_reexports मॉड्यूल होने पर क्या होता है? उत्तर: कुछ नहीं ।

समझाने के लिए, हमें यह समझने की आवश्यकता है कि एएसटी कैसे पहचानकर्ताओं का प्रतिनिधित्व करता है । प्रत्येक फ़ंक्शन का नाम, चर, मॉड्यूल, आदि। एक स्ट्रिंग के रूप में संग्रहीत नहीं, बल्कि एक अपारदर्शी प्रतीक के रूप में , जो अनिवार्य रूप से प्रत्येक पहचानकर्ता के लिए एक पहचान संख्या है। संकलक एक अलग हैश तालिका संग्रहीत करता है, जो हमें आवश्यक होने पर प्रतीक के सुपाठ्य नाम को पुनर्स्थापित करने की अनुमति देता है (उदाहरण के लिए, जब एक सिंटैक्स त्रुटि को मुद्रित करते हुए)। जब कंपाइलर __test_reexports मॉड्यूल बनाता है, तो यह पहचानकर्ता के लिए एक नया प्रतीक उत्पन्न करता है, इसलिए, संकलक द्वारा उत्पन्न __test_reexports आपके जेनेरिक मॉड्यूल के साथ एक ही नाम का हो सकता है, यह अपने प्रतीक का उपयोग नहीं करेगा। यह तकनीक कोड पीढ़ी के दौरान नाम टकराव को रोकती है और रस्ट मैक्रो सिस्टम की स्वच्छता का आधार है।

चरण 2: स्ट्रैपिंग उत्पन्न करना

अब जब हमारे परीक्षण हमारे टोकरे की जड़ से सुलभ हैं, तो हमें उनके साथ कुछ करने की आवश्यकता है। libsyntax एक ऐसा मॉड्यूल बनाता है:

 pub mod __test { extern crate test; const TESTS: &'static [self::test::TestDescAndFn] = &[/*...*/]; #[main] pub fn main() { self::test::test_static_main(TESTS); } } 

हालांकि यह रूपांतरण सरल है, यह हमें इस बारे में बहुत जानकारी देता है कि वास्तव में परीक्षण कैसे किए जाते हैं। टेस्ट को एक सरणी में एकत्र किया जाता है और टेस्ट test_static_main को पास किया जाता है, जिसे test_static_main कहा जाता है। हम TestDescAndFn क्या है पर लौट TestDescAndFn , लेकिन फिलहाल मुख्य निष्कर्ष यह है कि एक टोकरा है जिसे परीक्षण कहा जाता है , जो रस्ट कोर का हिस्सा है और परीक्षण के लिए पूरे रनटाइम को लागू करता है। test इंटरफ़ेस अस्थिर है, इसलिए इसके साथ बातचीत करने का एकमात्र स्थिर तरीका मैक्रो #[test] ।

चरण 3: एक परीक्षण वस्तु उत्पन्न करना

यदि आपने पहले रस्ट में परीक्षण लिखे थे, तो आप परीक्षण कार्यों के लिए उपलब्ध कुछ वैकल्पिक विशेषताओं से परिचित हो सकते हैं। उदाहरण के लिए, यदि हम परीक्षण से घबराहट पैदा करने की अपेक्षा करते हैं तो परीक्षण को #[should_panic] साथ एनोटेट किया जा सकता है। यह कुछ इस तरह दिखता है:

 #[test] #[should_panic] fn foo() { panic!("intentional"); } 

इसका मतलब है कि हमारे परीक्षण सरल कार्यों से अधिक हैं और कॉन्फ़िगरेशन जानकारी है। test इस कॉन्फ़िगरेशन डेटा को TestDesc नामक संरचना में एन्कोड करता है। टोकरे में प्रत्येक परीक्षण समारोह के लिए, libsyntax अपनी विशेषताओं का विश्लेषण करेगा और TestDesc का एक उदाहरण उत्पन्न TestDesc । यह तब TestDesc और परीक्षण फ़ंक्शन को तार्किक संरचना TestDescAndFn , जिसके test_static_main काम करता test_static_main । इस परीक्षण के लिए, TestDescAndFn का उत्पन्न उदाहरण इस तरह दिखता है:

 self::test::TestDescAndFn { desc: self::test::TestDesc { name: self::test::StaticTestName("foo"), ignore: false, should_panic: self::test::ShouldPanic::Yes, allow_fail: false, }, testfn: self::test::StaticTestFn(|| self::test::assert_test_result(::crate::__test_reexports::foo())), } 

एक बार जब हमने इन परीक्षण वस्तुओं का एक सरणी बनाया है, तो वे चरण 2 में उत्पन्न बंधन के माध्यम से परीक्षण धावक को दिए जाते हैं। हालांकि इस कदम को दूसरे चरण का हिस्सा माना जा सकता है, मैं इसे एक अलग अवधारणा के रूप में ध्यान आकर्षित करना चाहता हूं, क्योंकि यह कस्टम परीक्षण को लागू करने की कुंजी होगी चौखटे, लेकिन यह एक और ब्लॉग पोस्ट होगा।

आफ्टरवर्ड: रिसर्च मेथड्स

हालाँकि मुझे संकलक स्रोतों से बहुत सी जानकारी मिली, लेकिन मैं यह पता लगाने में सक्षम था कि संकलक क्या करता है, यह देखने का एक बहुत सरल तरीका है। कंपाइलर नाइटली बिल्ड में एक अस्थिर ध्वज होता है जिसे unpretty कहा जाता है, जिसका उपयोग आप मैक्रो का विस्तार करने के बाद मॉड्यूल के स्रोत कोड को प्रिंट करने के लिए कर सकते हैं:

 $ rustc my_mod.rs -Z unpretty=hir 

अनुवादक का नोट

के लिए दिलचस्प है, मैं मैक्रो-प्रकटीकरण के बाद परीक्षण मामले के कोड का वर्णन करूंगा:

कस्टम स्रोत कोड:

 #[test] fn my_test() { assert!(2+2 == 4); } fn main() {} 

मैक्रो का विस्तार करने के बाद कोड:

 #[prelude_import] use std::prelude::v1::*; #[macro_use] extern crate std as std; #[test] pub fn my_test() { if !(2 + 2 == 4) { { ::rt::begin_panic("assertion failed: 2 + 2 == 4", &("test_test.rs", 3u32, 3u32)) } }; } #[allow(dead_code)] fn main() { } pub mod __test_reexports { pub use super::my_test; } pub mod __test { extern crate test; #[main] pub fn main() -> () { test::test_main_static(TESTS) } const TESTS: &'static [self::test::TestDescAndFn] = &[self::test::TestDescAndFn { desc: self::test::TestDesc { name: self::test::StaticTestName("my_test"), ignore: false, should_panic: self::test::ShouldPanic::No, allow_fail: false, }, testfn: self::test::StaticTestFn(::__test_reexports::my_test), }]; }