मैक्रो और गतिशील मेमोरी के बिना सी ++ में टेस्ट

परीक्षण के लिए कई लोकप्रिय पुस्तकालय, उदाहरण के लिए Google टेस्ट, Catch2, Boost.Test, मैक्रोज़ के उपयोग के लिए बहुत अधिक बंधे हुए हैं, इसलिए इन पुस्तकालयों पर परीक्षण के उदाहरण के रूप में, आप आमतौर पर इस तरह की एक तस्वीर देखते हैं:

namespace { // Tests the default c'tor. TEST(MyString, DefaultConstructor) { const MyString s; EXPECT_STREQ(nullptr, s.c_string()); EXPECT_EQ(0u, s.Length()); } const char kHelloString[] = "Hello, world!"; // Tests the c'tor that accepts a C string. TEST(MyString, ConstructorFromCString) { const MyString s(kHelloString); EXPECT_EQ(0, strcmp(s.c_string(), kHelloString)); EXPECT_EQ(sizeof(kHelloString)/sizeof(kHelloString[0]) - 1, s.Length()); } // Tests the copy c'tor. TEST(MyString, CopyConstructor) { const MyString s1(kHelloString); const MyString s2 = s1; EXPECT_EQ(0, strcmp(s2.c_string(), kHelloString)); } } // namespace 

C ++ में मैक्रों सावधान हैं, वे परीक्षण बनाने के लिए पुस्तकालयों में इतने संपन्न क्यों हैं?

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

प्रसिद्ध पुस्तकालय जिसमें एक एकल मैक्रो के बिना दृष्टिकोण को लागू किया जाता है, वह है टुट-फ्रेमवर्क । आइए ट्यूटोरियल से उसका उदाहरण देखें:

 #include <tut/tut.hpp> namespace tut { struct basic{}; typedef test_group<basic> factory; typedef factory::object object; } namespace { tut::factory tf("basic test"); } namespace tut { template<> template<> void object::test<1>() { ensure_equals("2+2=?", 2+2, 4); } } 

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

 template <class Data> class test_object : public Data { /** * Default do-nothing test. */ template <int n> void test() { called_method_was_a_dummy_test_ = true; } } 

अब जब आप ऐसा परीक्षण लिखते हैं:

 template<> template<> void object::test<1>() { ensure_equals("2+2=?", 2+2, 4); } 

आप वास्तव में एक विशिष्ट संख्या N = 1 के लिए एक परीक्षण विधि विशेषज्ञता बनाते हैं (यह वास्तव में template<>template<> के लिए खड़ा है)। test<N>() कहकर test<N>() परीक्षण रनटाइम समझ सकता है कि क्या यह एक वास्तविक परीक्षण था या यह परीक्षण निष्पादित होने के बाद called_method_was_a_dummy_test_ नामक मान को देख रहा था।

अगला, जब आप एक परीक्षण समूह घोषित करते हैं:

 tut::factory tf("basic test"); 

सबसे पहले, आप एक निश्चित स्थिरांक के लिए सभी test<N> गणना करते हैं जो कि पुस्तकालय को वायर्ड किया जाता है, और दूसरी बात, साइड इफेक्ट से, आप समूह के बारे में वैश्विक कंटेनर (समूह का नाम और सभी परीक्षण कार्यों के पते) के बारे में जानकारी जोड़ते हैं।

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

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

 template<> template<> void object::test<1>() { set_name("2+2"); // Set test name to be shown in test report ensure_equals("2+2=?", 2+2, 4); } 

एक और समस्या यह है कि टुट टेस्ट रन पर्यावरण ऐसे किसी भी घटना के बारे में कुछ भी नहीं जानता है जैसे कि एक परीक्षण की शुरुआत। वातावरण object::test<N>() निष्पादित करता object::test<N>() और यह अग्रिम में नहीं पता है कि क्या परीक्षण किसी दिए गए N के लिए लागू किया गया है, या यह केवल एक स्टब है। वह केवल यह called_method_was_a_dummy_test_ कि परीक्षण कब called_method_was_a_dummy_test_ मूल्य called_method_was_a_dummy_test_ । यह सुविधा सीआई सिस्टम में खुद को बहुत अच्छी तरह से नहीं दिखाती है, जो कि उस आउटपुट को समूहित करने में सक्षम हैं जो परीक्षण की शुरुआत और अंत के बीच बनाया गया है।

हालांकि, मेरी राय में, मुख्य चीज जिसे सुधार किया जा सकता है (एक "घातक दोष") अतिरिक्त सहायक कोड की उपस्थिति है जो परीक्षण लिखने के लिए आवश्यक है। ट्यूटोरियल टुट-फ्रेमवर्क में बहुत सारी चीजें हैं: पहले एक निश्चित वर्ग struct basic{} बनाना प्रस्तावित है, और इस से जुड़े ऑब्जेक्ट के तरीकों के रूप में परीक्षणों का वर्णन करें। इस वर्ग में, आप उन तरीकों और डेटा को परिभाषित कर सकते हैं, जिन्हें आप परीक्षण समूह में उपयोग करना चाहते हैं, और निर्माता और विध्वंसक परीक्षण के निष्पादन को फ्रेम करते हैं, जेयूनिट से स्थिरता के रूप में ऐसी चीज बनाते हैं। टुट के साथ मेरे अभ्यास में, यह ऑब्जेक्ट लगभग हमेशा खाली होता है, लेकिन यह कोड की एक निश्चित संख्या के साथ सूख जाता है।

तो, हम बाइक कार्यशाला में जाते हैं और एक छोटे पुस्तकालय के रूप में विचार को व्यवस्थित करने का प्रयास करते हैं।

परीक्षण लाइब्रेरी में यह न्यूनतम परीक्षण फ़ाइल जैसा दिखता है:

 // Test group for std::vector (illustrative purposes) #include "tested.h" #include <vector> template<> void tested::Case<CASE_COUNTER>(tested::IRuntime* runtime) { runtime->StartCase("emptiness"); std::vector<int> vec; tested::Is(vec.empty(), "Vector must be empty by default"); } template<> void tested::Case<CASE_COUNTER>(tested::IRuntime* runtime) { runtime->StartCase("AddElement"); std::vector<int> vec; vec.push_back(1); tested::Is(vec.size() == 1); tested::Is(vec[0] == 1); tested::FailIf(vec.empty()); } void LinkVectorTests() { static tested::Group<CASE_COUNTER> x("std.vector", __FILE__); } 

मैक्रो की कमी के अलावा, लाइब्रेरी के अंदर गतिशील मेमोरी के उपयोग की अनुपस्थिति बोनस है।

परीक्षण मामलों की परिभाषा

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

 template <int N> static void Case(IRuntime* runtime) { throw TheCaseIsAStub(); } 

पुस्तकालय उपयोगकर्ताओं द्वारा लिखे गए परीक्षण मामले इस पद्धति के विशेषज्ञ हैं। फ़ंक्शन को स्थिर घोषित किया जाता है, अर्थात प्रत्येक अनुवाद इकाई में, हम ऐसे स्पेशलाइज़ेशन बनाते हैं जो लिंक करने के दौरान एक दूसरे के साथ नाम से इंटरसेक्ट नहीं करते हैं।

ऐसा नियम है कि पहले आपको StartCase() को कॉल करने की आवश्यकता है, जिसमें आप परीक्षण के नाम जैसी चीजें पास कर सकते हैं और शायद कुछ अन्य चीजें जो अभी भी विकास में हैं।

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

पंजीकरण

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

 static tested::Group<CASE_COUNTER> x("std.vector", __FILE__); 

निर्माणकर्ता निर्दिष्ट नाम के साथ एक समूह बनाता है और इसे सभी Case<N> मामलों में जोड़ता है जो इसे वर्तमान अनुवाद इकाई में पाता है। यह पता चला है कि एक अनुवाद इकाई में आपके दो समूह नहीं हो सकते। इसका अर्थ यह भी है कि आप एक समूह को कई अनुवाद इकाइयों में नहीं बाँट सकते।

टेम्प्लेट का पैरामीटर है कि बनाए गए समूह के लिए वर्तमान अनुवाद इकाई में देखने के लिए कितने परीक्षण मामले हैं।

जोड़ने

उपरोक्त उदाहरण में, परीक्षण का निर्माण :: समूह () ऑब्जेक्ट फ़ंक्शन के अंदर होता है जिसे हमें परीक्षणों को पंजीकृत करने के लिए अपने आवेदन से कॉल करना चाहिए:

 void LinkStdVectorTests() { static tested::Group<CASE_COUNTER> x("std.vector", __FILE__); } 

एक फ़ंक्शन की हमेशा आवश्यकता नहीं होती है, कभी-कभी आप tested::Group ऑब्जेक्ट का एक ऑब्जेक्ट घोषित कर सकते हैं tested::Group किसी फ़ाइल के अंदर tested::Group क्लास। हालाँकि, मेरा अनुभव यह है कि लिंकर कभी-कभी पूरी फाइल को "ऑप्टिमाइज़" कर देता है अगर वह लाइब्रेरी के अंदर इकट्ठा हो जाए, और मुख्य एप्लिकेशन में से कोई भी इस cpp फ़ाइल के किसी भी वर्ण का उपयोग नहीं करता है:

 calc.lib <- calc_test.lib(calc_test.cpp) ^ ^ | | app.exe run_test.exe 

जब calc_test.cpp को run_test.exe स्रोत से लिंक नहीं किया जाता है, तो लिंकर बस एक स्थिर वस्तु के निर्माण के साथ-साथ इस फ़ाइल को पूरी तरह से विचार से हटा देता है, इस तथ्य के बावजूद कि इसके साइड इफेक्ट्स हमें चाहिए।

यदि किस श्रृंखला में run_test.exe से परिणाम होता है, तो निष्पादन योग्य फ़ाइल में स्थिर ऑब्जेक्ट दिखाई देगा। और यह बिल्कुल नहीं है कि यह कैसे किया जाता है, उदाहरण के लिए:

 void LinkStdVectorTests() { static tested::Group<CASE_COUNTER> x("std.vector", __FILE__); } 

या तो:

 static tested::Group<CASE_COUNTER> x("std.vector", __FILE__); void LinkStdVectorTests() { } 

मेरी राय में, पहला विकल्प बेहतर है, क्योंकि निर्माणकर्ता को मुख्य () की शुरुआत के बाद बुलाया जाता है, और इस प्रक्रिया पर आवेदन का कुछ नियंत्रण होता है।

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

मैक्रो

मैंने वादा किया था कि कोई मैक्रोज़ नहीं होगा, लेकिन यह है - CASE_COUNTER । काम करने का विकल्प यह है कि इसका उपयोग __COUNTER__ द्वारा किया जाता है, एक मैक्रो जो प्रत्येक बार अनुवाद इकाई के अंदर उपयोग किए जाने वाले संकलक को बढ़ाता है।
GCC, CLANG, MSVC द्वारा समर्थित, लेकिन मानक नहीं। यदि यह निराशाजनक है, तो यहां कुछ विकल्प दिए गए हैं:

• संख्या 0, 1, 2 का उपयोग करें
• मानक __LINE__ उपयोग करें।
• 80 के स्तर के जादू का उपयोग करें। आप "कॉन्स्ट्रेक्स काउंटर" की खोज कर सकते हैं और उस कंपाइलर को खोजने की कोशिश करेंगे, जिस पर वह काम करेगा।

__LINE__ साथ समस्या यह है कि टेम्पलेट विकल्पों में बड़ी संख्या का उपयोग करने से एक बड़ा निष्पादन योग्य फ़ाइल आकार बनता है। यही कारण है कि मैंने समूह में परीक्षणों की अधिकतम संख्या के रूप में हस्ताक्षरित चार पैटर्न के प्रकार को सीमित कर दिया।

गतिशील स्मृति की विफलता

यह पता चला कि परीक्षण दर्ज करते समय, आप गतिशील मेमोरी का उपयोग नहीं कर सकते हैं, जिसका मैंने उपयोग किया था। यह संभव है कि आपके वातावरण में गतिशील मेमोरी नहीं है या आप परीक्षण मामलों में मेमोरी लीक की खोज का उपयोग करते हैं, इसलिए परीक्षण निष्पादन पर्यावरण का हस्तक्षेप वह नहीं है जिसकी आपको आवश्यकता है। Google टेस्ट इसी से जूझ रहा है, यहाँ एक स्निपेट है:

 // Use the RAII idiom to flag mem allocs that are intentionally never // deallocated. The motivation is to silence the false positive mem leaks // that are reported by the debug version of MS's CRT which can only detect // if an alloc is missing a matching deallocation. // Example: // MemoryIsNotDeallocated memory_is_not_deallocated; // critical_section_ = new CRITICAL_SECTION; class MemoryIsNotDeallocated 

और हम बस मुश्किलें पैदा नहीं कर सकते।

फिर हमें परीक्षणों की सूची कैसे मिलती है? ये अधिक तकनीकी इंटर्न हैं, जो स्रोत कोड में देखना आसान है, लेकिन मैं आपको वैसे भी बताऊंगा।

एक समूह बनाते समय, इसका वर्ग tested::CaseCollector<CASE_COUNTER>::collect लिए एक संकेतक प्राप्त करेगा tested::CaseCollector<CASE_COUNTER>::collect फ़ंक्शन, जो सभी अनुवाद इकाई परीक्षणों को एक सूची में एकत्रित करेगा। यहां बताया गया है कि यह कैसे काम करता है:

 // Make the anonymouse namespace to have instances be hidden to specific translation unit namespace { template <Ordinal_t N> struct CaseCollector { // Test runtime that collects the test case struct CollectorRuntime final : IRuntime { void StartCase(const char* caseName, const char* description = nullptr) final { // the trick is exit from test case function into the collector via throw throw CaseIsReal(); } }; // Finds the Case<N> function in current translation unit and adds into the static list. It uses the // reverse order, so the case executed in order of appearance in C++ file. static CaseListEntry* collect(CaseListEntry* tail) { CaseListEntry* current = nullptr; CollectorRuntime collector; try { Case<N>(&collector); } catch (CaseIsStub) { current = tail; } catch (CaseIsReal) { s_caseListEntry.CaseProc = Case<N>; s_caseListEntry.Next = tail; s_caseListEntry.Ordinal = N; current = &s_caseListEntry; } return CaseCollector<N - 1>::collect(current); } private: static CaseListEntry s_caseListEntry; }; // This static storage will be instantiated in any cpp file template <Ordinal_t N> CaseListEntry CaseCollector<N>::s_caseListEntry; } 

यह पता चलता है कि प्रत्येक अनुवाद इकाई में CaseListEntry CaseCollector \ :: s_caseListEntry प्रकार के कई स्थिर चर बनाए जाते हैं, जो परीक्षण सूची के तत्व हैं, और संग्रह () विधि इन तत्वों को एक एकल कनेक्ट की गई सूची में एकत्रित करती है। लगभग उसी तरह, सूची परीक्षणों के समूह बनाती है, लेकिन पैटर्न और पुनरावृत्ति के बिना।

संरचना

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

मेरा दृष्टिकोण यह है कि हम पुस्तकालय को फ्रंट-एंड में विभाजित करते हैं - यह परीक्षण किया जाता है। स्वयं और बैक-एंड लाइब्रेरी। परीक्षण लिखने के लिए आपको केवल परीक्षण की आवश्यकता होती है। एच, जो अब C ++ 17 है (std :: std :: string_view के कारण) लेकिन यह माना जाता है कि C ++ 98 होगा। Tested.h वास्तव में पंजीकरण करता है और परीक्षण के लिए खोज करता है, एक न्यूनतम सुविधाजनक लॉन्च विकल्प, साथ ही परीक्षण (समूहों, परीक्षण मामलों के कार्यों के पते) को निर्यात करने की क्षमता। बैक-एंड लाइब्रेरीज़ जो अभी तक मौजूद नहीं हैं, वे आउटपुट कार्यक्षमता के उपयोग से परिणाम के परिणाम और लॉन्चिंग के संदर्भ में जो कुछ भी ज़रूरत है कर सकते हैं। उसी तरह, आप लॉन्च को अपनी परियोजना की जरूरतों के लिए अनुकूलित कर सकते हैं।

परिणाम

परीक्षण किए गए पुस्तकालय ( जीथूब कोड ) को अभी भी कुछ स्थिरीकरण की आवश्यकता है। निकट भविष्य में, अतुल्यकालिक परीक्षण (WebAssembly में एकीकरण परीक्षणों के लिए आवश्यक) को चलाने की क्षमता जोड़ें और परीक्षणों के आकार का संकेत दें। मेरी राय में, पुस्तकालय अभी भी उत्पादन उपयोग के लिए बिल्कुल तैयार नहीं है, लेकिन मैंने अचानक बहुत समय बिताया और मंच बंद हो गया है, एक सांस लें और समुदाय से प्रतिक्रिया मांगें। क्या आप इस तरह की लाइब्रेरी का उपयोग करने के लिए इच्छुक होंगे? शायद C ++ शस्त्रागार में कोई अन्य विचार हैं क्योंकि मैक्रोज़ के बिना एक पुस्तकालय बनाना संभव होगा? क्या समस्या का ऐसा बयान दिलचस्प है?