एसएमएस और पंजीकरण के बिना सी परीक्षण

हाल ही में, ज़ीरोकॉस्ट ने एक दिलचस्प लेख लिखा, "मैक्रो और गतिशील मेमोरी के बिना सी ++ में टेस्ट" , जिसमें सी ++ कोड के परीक्षण के लिए एक न्यूनतर रूपरेखा की चर्चा है। लेखक (लगभग) परीक्षण दर्ज करने के लिए मैक्रोज़ के उपयोग से बचने में कामयाब रहे, लेकिन उनके बजाय कोड में "जादू" टेम्पलेट दिखाई दिए, जो व्यक्तिगत रूप से मुझे लगता है, माफ करना, अकल्पनीय रूप से बदसूरत। लेख पढ़ने के बाद, मुझे असंतोष की एक अस्पष्ट भावना थी, क्योंकि मुझे पता था कि क्या बेहतर किया जा सकता है। मुझे तुरंत याद नहीं आ रहा था कि मैं कहां जाऊं, लेकिन मैंने टेस्ट कोड जरूर देखा , जिसमें उन्हें रजिस्टर करने के लिए एक भी अतिरिक्त चरित्र नहीं है:

void test_object_addition() { ensure_equals("2 + 2 = ?", 2 + 2, 4); } 

अंत में, मुझे याद आया कि इस ढांचे को कटर कहा जाता है और यह अपने तरीके से परीक्षण कार्यों की पहचान करने के लिए एक प्रतिभाशाली तरीके का उपयोग करता है।

(CC BY-SA के तहत कटर वेबसाइट से लिया गया KDPV।)

चाल क्या है?

टेस्ट कोड को एक अलग साझा लाइब्रेरी में इकट्ठा किया जाता है। परीक्षण कार्यों को निर्यात किए गए पुस्तकालय प्रतीकों से निकाला जाता है और नामों से पहचाना जाता है। टेस्ट एक विशेष बाहरी उपयोगिता द्वारा किए जाते हैं। सपत्नीक बैठे रहे।

 $ cat test_addition.c #include <cutter.h> void test_addition() { cut_assert_equal_int(2 + 2, 5); } 

 $ cc -shared -o test_addition.so \ -I/usr/include/cutter -lcutter \ test_addition.c 

 $ cutter . F ========================================================================= Failure: test_addition <2 + 2 == 5> expected: <4> actual: <5> test_addition.c:5: void test_addition(): cut_assert_equal_int(2 + 2, 5, ) ========================================================================= Finished in 0.000943 seconds (total: 0.000615 seconds) 1 test(s), 0 assertion(s), 1 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s) 0% passed 

यहाँ कटर प्रलेखन से एक उदाहरण है । आप ऑटोटूल से जुड़ी हर चीज को सुरक्षित रूप से स्क्रॉल कर सकते हैं, और केवल कोड को देख सकते हैं। रूपरेखा थोड़ी अजीब है, हाँ, सब कुछ जापानी की तरह।

मैं कार्यान्वयन सुविधाओं के बारे में बहुत विस्तार में नहीं जाऊंगा। मेरे पास भी पूर्णरूपेण (और यहां तक ​​कि कम से कम ड्राफ्ट) कोड नहीं है, क्योंकि व्यक्तिगत रूप से मुझे वास्तव में इसकी आवश्यकता नहीं है (जंग में सब कुछ बॉक्स से बाहर है)। हालांकि, इच्छुक लोगों के लिए, यह एक अच्छा व्यायाम हो सकता है।

विवरण और कार्यान्वयन विकल्प

कटर दृष्टिकोण का उपयोग करके परीक्षण के लिए एक रूपरेखा लिखते समय कुछ ऐसे कार्यों पर विचार करें जिन्हें आपको हल करने की आवश्यकता है।

निर्यात किए गए कार्य हो रहे हैं

सबसे पहले, आप किसी भी तरह परीक्षण कार्यों के लिए प्राप्त करने की आवश्यकता है। C ++ मानक, ज़ाहिर है, साझा पुस्तकालयों का बिल्कुल भी वर्णन नहीं करता है। विंडोज ने हाल ही में एक लिनक्स सबसिस्टम हासिल किया है, जो सभी तीन प्रमुख ऑपरेटिंग सिस्टमों को पोसिक्स में कम करने की अनुमति देता है। जैसा कि आप जानते हैं, POSIX सिस्टम फ़ंक्शंस dlopen() , dlsym() , dlclose() प्रदान करता है, dlsym() मदद से आप किसी फ़ंक्शन का पता प्राप्त कर सकते हैं, उसके प्रतीक का नाम जान सकते हैं, और ... बस इतना ही। POSIX द्वारा भरी हुई लाइब्रेरी में निहित कार्यों की सूची का खुलासा नहीं किया गया है।

दुर्भाग्य से (हालांकि सौभाग्य से), पुस्तकालय से निर्यात किए गए सभी कार्यों की खोज करने के लिए कोई मानक, पोर्टेबल तरीका नहीं है। शायद, यह तथ्य कि एक पुस्तकालय की अवधारणा सभी प्लेटफार्मों पर मौजूद नहीं है (पढ़ें: एम्बेडेड) किसी तरह यहां शामिल है। लेकिन वह बात नहीं है। मुख्य बात यह है कि आपको प्लेटफ़ॉर्म-विशिष्ट सुविधाओं का उपयोग करना होगा।

एक प्रारंभिक सन्निकटन के रूप में, आप बस एनएम उपयोगिता को कॉल कर सकते हैं:

 $ cat test.cpp void test_object_addition() { } 

 $ clang -shared test.cpp 

 $ nm -gj ./a.out __Z20test_object_additionv dyld_stub_binder 

इसके उत्पादन को पार्स और dlsym() उपयोग करें।

गहन आत्मनिरीक्षण के लिए, पुस्तकालयों जैसे कि libelf , libMachO , pe-parse उपयोगी होते हैं, जो आपको प्रोग्रामेटिक रूप से निष्पादन योग्य फ़ाइलों और पुस्तकालयों के हितों के प्लेटफार्मों को पार्स करने की अनुमति देते हैं। वास्तव में, एनएम और कंपनी सिर्फ उनका उपयोग करते हैं।

परीक्षण समारोह छानने

जैसा कि आपने देखा होगा, पुस्तकालयों में कुछ अजीब अक्षर होते हैं:

 __Z20test_object_additionv dyld_stub_binder 

यह वही है जो __Z20test_object_additionv , जब हम फ़ंक्शन को सिर्फ test_object_addition ? और यह क्या बचा है dyld_stub_binder ?

" __Z20... " अक्षर __Z20... तथाकथित नाम सजावट (नाम प्रबंध) है। सी ++ संकलन सुविधा, कुछ भी नहीं किया जा सकता है, इसके साथ रहें। यह वह कार्य है जिसे सिस्टम के दृष्टिकोण से कहा जाता है (और dlsym() )। किसी व्यक्ति को उनके सामान्य रूप में दिखाने के लिए, आप पुस्तकालयों का उपयोग कर सकते हैं जैसे libdemangle । बेशक, आपको जिस लाइब्रेरी की ज़रूरत है, वह आपके द्वारा उपयोग किए जाने वाले कंपाइलर पर निर्भर करती है, लेकिन सजावट का प्रारूप आमतौर पर प्लेटफॉर्म के ढांचे के भीतर समान होता है।

dyld_stub_binder जैसे विचित्र कार्यों के लिए, ये भी प्लेटफ़ॉर्म की विशेषताएं हैं जिन्हें ध्यान में रखा जाना चाहिए। परीक्षण शुरू करते समय आपको किसी भी फ़ंक्शन को कॉल करने की आवश्यकता नहीं है, क्योंकि वहां कोई मछली नहीं है।

इस विचार की एक तार्किक निरंतरता समारोह को नाम से फ़िल्टर करना है। उदाहरण के लिए, आप केवल नाम में test साथ फ़ंक्शन चला सकते हैं। या tests नाम स्थान से सिर्फ कार्य करता है। और समूह परीक्षणों के लिए नेस्टेड नेमस्पेस का भी उपयोग करें। आपकी कल्पना की कोई सीमा नहीं है।

एक निष्पादन योग्य परीक्षण के संदर्भ में पारित करना

परीक्षणों के साथ ऑब्जेक्ट फाइलें एक साझा पुस्तकालय में एकत्र की जाती हैं, जिनमें से कोड का निष्पादन पूरी तरह से एक बाहरी उपयोगिता-चालक - cutter द्वारा कटर द्वारा नियंत्रित किया जाता है। तदनुसार, आंतरिक परीक्षण फ़ंक्शन इसका उपयोग कर सकते हैं।

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

इस मामले में, परीक्षण कार्यों के लिए तर्कों की आवश्यकता नहीं है, लेकिन सभी उन्नत सुविधाओं को बनाए रखें, जैसे कि परीक्षण किए गए मामलों के मनमाने ढंग से नामकरण:

 void test_vector_add_element() { testing::description("vector size grows after push_back()"); } 

description() फ़ंक्शन वैश्विक वैरिएबल के माध्यम से सशर्त IRuntime तक पहुंचता है और इस प्रकार एक व्यक्ति के लिए एक टिप्पणी को पारित कर सकता है। वैश्विक संदर्भ का उपयोग करने की सुरक्षा की गारंटी फ्रेमवर्क द्वारा दी गई है और यह परीक्षण लेखक की जिम्मेदारी नहीं है।

इस दृष्टिकोण के साथ, कोड में कम बयानों के साथ तुलनात्मक बयानों और आंतरिक परीक्षण कार्यों के संदर्भ में बदलाव होगा जिन्हें मुख्य से बुलाया जा सकता है।

कंस्ट्रक्टर और डिस्ट्रक्टर्स

चूंकि परीक्षणों का निष्पादन पूरी तरह से चालक द्वारा नियंत्रित किया जाता है, इसलिए यह परीक्षणों के आसपास अतिरिक्त कोड निष्पादित कर सकता है।

कटर पुस्तकालय इसके लिए निम्नलिखित कार्यों का उपयोग करता है:

• cut_setup() - प्रत्येक व्यक्तिगत परीक्षण से पहले
• cut_teardown() - प्रत्येक व्यक्तिगत परीक्षण के बाद
• cut_startup() - सभी परीक्षण चलाने से पहले
• cut_shutdown() - सभी परीक्षणों के पूरा होने के बाद

इन कार्यों को केवल तभी कहा जाता है जब परीक्षण फ़ाइल में परिभाषित किया गया हो। आप उन्हें परीक्षण वातावरण (तैयारी) की तैयारी और सफाई में डाल सकते हैं: आवश्यक अस्थायी फाइलें, परीक्षण की गई वस्तुओं का जटिल सेटअप, और परीक्षण के अन्य एंटीपर्टर्न बना सकते हैं।

C ++ के लिए, अधिक मुहावरेदार इंटरफ़ेस के साथ आना संभव है:

• अधिक वस्तु उन्मुख और सुरक्षित प्रकार
• बेहतर RAII अवधारणा समर्थन के साथ
• आस्थगित निष्पादन के लिए लंबोदा का उपयोग करना
• परीक्षण निष्पादन संदर्भ शामिल करना

लेकिन अब मैं इसके बारे में फिर से विस्तार से सोच रहा हूं।

स्व-निहित परीक्षण निष्पादन योग्य

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

अन्य

कटर और अन्य रूपरेखाओं में कई अन्य उपयोगी चीजें भी होती हैं जो परीक्षण लिखते समय जीवन को आसान बना सकती हैं:

• लचीला और एक्स्टेंसिबल परीक्षण बयान
• फ़ाइलों से निर्माण और परीक्षण डेटा प्राप्त करना
• स्टैक ट्रेस अध्ययन, अपवाद और ड्रॉप हैंडलिंग
• परीक्षण के अनुकूलन "टूटने का स्तर"
• कई प्रक्रियाओं में परीक्षण चल रहा है

यह आपकी बाइक लिखते समय मौजूदा चौखटे को देखने लायक है। UX बहुत गहरा विषय है।

निष्कर्ष

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

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

इस दृष्टिकोण के नुकसान में मुख्य कोड के रूप में एक ही फ़ाइल (उसी अनुवाद इकाई) में परीक्षण रखने की कठिनाई शामिल है। दुर्भाग्य से, इस मामले में, अतिरिक्त संकेत के बिना, यह पता लगाना संभव नहीं है कि किन कार्यों को लॉन्च करने की आवश्यकता है और कौन से नहीं। सौभाग्य से, सी ++ में यह आमतौर पर विभिन्न फाइलों में परीक्षण और कार्यान्वयन वितरित करने के लिए प्रथागत है।

मैक्रों के अंतिम निपटान के लिए, यह मुझे लगता है कि सिद्धांत रूप में उन्हें छोड़ नहीं दिया जाना चाहिए। मैक्रों, उदाहरण के लिए, कोड के दोहराव से बचने के लिए तुलनात्मक बयान लिखने की अनुमति देते हैं:

 void test_object_addition() { ensure_equals(2 + 2, 5); } 

लेकिन एक ही समय में त्रुटियों के मामले में मुद्दे की एक ही सूचना सामग्री रखते हुए:

 Failure: test_object_addition <ensure_equals(2 + 2, 5)> expected: <5> actual: <4> test.c:5: test_object_addition() 

फ़ंक्शन का परीक्षण किया जा रहा है, फ़ाइल का नाम, और सिद्धांत में फ़ंक्शन के प्रारंभ की लाइन संख्या एकत्र की जा रही लाइब्रेरी में मौजूद डिबग जानकारी से निकाली जा सकती है। तुलनात्मक भावों के अपेक्षित और वास्तविक मूल्य का पता ensure_equals() फ़ंक्शन से ensure_equals() । मैक्रो आपको परीक्षण विवरण की मूल वर्तनी को "पुनर्स्थापित" करने की अनुमति देता है, जिससे यह अधिक स्पष्ट है कि मूल्य 4 की उम्मीद क्यों है।

हालांकि, यह हर किसी के लिए नहीं है। क्या परीक्षण कोड के लिए मैक्रोज़ का लाभ वहाँ समाप्त होता है? मैंने इस क्षण के बारे में अभी तक सोचा नहीं था, जो आगे के लिए एक अच्छा क्षेत्र हो सकता है विकृतियों अनुसंधान। एक और अधिक दिलचस्प सवाल: क्या यह संभव है कि किसी भी तरह मैक्रो के बिना सी ++ के लिए एक नकली ढांचा बनाया जाए?

चौकस पाठक ने यह भी नोट किया कि कार्यान्वयन में वास्तव में कोई एसएमएस और एस्बेस्टोस नहीं हैं, जो पृथ्वी की पारिस्थितिकी और अर्थव्यवस्था के लिए निस्संदेह प्लस है।