🗿 ⏬ 🤶🏾 यूनिट परीक्षण C ++ और मॉक इंजेक्शन पैटर्न का उपयोग कर लक्षण 📓 👎🏿 🤘🏻

फिर से नमस्कार! "C ++ डेवलपर" पाठ्यक्रम में समूह में कक्षाएं शुरू होने से पहले एक सप्ताह से भी कम समय बचा है। इस संबंध में, हम इस पाठ्यक्रम के छात्रों के लिए विशेष रूप से अनुवादित उपयोगी सामग्री को साझा करना जारी रखते हैं।

टेम्प्लेट के साथ अपने कोड का यूनिट परीक्षण समय-समय पर खुद को याद दिलाता है। (आप अपने टेम्पलेट्स का परीक्षण कर रहे हैं, सही?) कुछ टेम्पलेट्स का परीक्षण करना आसान है। कुछ नहीं हैं। कभी-कभी परीक्षण किए गए टेम्पलेट में मॉक-कोड (स्टब) के कार्यान्वयन के बारे में स्पष्टता की कमी है। मैंने कई कारण देखे हैं कि कोड एम्बेड करना जटिल क्यों हो जाता है।

नीचे मैंने कोड कार्यान्वयन की लगभग बढ़ती जटिलता के साथ कुछ उदाहरण दिए।

टेम्पलेट कंस्ट्रक्टर में संदर्भ द्वारा एक प्रकार का तर्क और उसी प्रकार का ऑब्जेक्ट लेता है।
टेम्पलेट एक प्रकार का तर्क लेता है। निर्माता तर्क की एक प्रति बनाता है या बस इसे स्वीकार नहीं करता है।
एक टेम्पलेट एक प्रकार का तर्क लेता है और वर्चुअल फ़ंक्शन के बिना कई इंटरकनेक्ट किए गए टेम्पलेट बनाता है।

चलो एक साधारण से शुरू करते हैं।

टेम्पलेट कंस्ट्रक्टर में संदर्भ द्वारा एक प्रकार का तर्क और उसी प्रकार का ऑब्जेक्ट लेता है

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

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

उदाहरण के लिए:

template <class T> class TemplateUnderTest { T *t_; public: TemplateUnderTest(T *t) : t_(t) {} void SomeMethod() { t->DoSomething(); t->DoSomeOtherThing(); } }; struct MockT { void DoSomething() { // Some assertions here. } void DoSomeOtherThing() { // Some more assertions here. } }; class UnitTest { void Test1() { MockT mock; TemplateUnderTest<MockT> test(&mock); test.SomeMethod(); assert(DoSomethingWasCalled(mock)); assert(DoSomeOtherThingWasCalled(mock)); } };

टेम्पलेट एक प्रकार का तर्क लेता है। निर्माता तर्क की एक प्रति बनाता है या बस इसे स्वीकार नहीं करता है

इस मामले में, एक्सेस अधिकारों के कारण टेम्पलेट के अंदर ऑब्जेक्ट तक पहुंच संभव नहीं हो सकती है। आप friend वर्गों का उपयोग कर सकते हैं।

 template <class T> class TemplateUnderTest { T t_; friend class UnitTest; public: void SomeMethod() { t.DoSomething(); t.DoSomeOtherThing(); } }; class UnitTest { void Test2() { TemplateUnderTest<MockT> test; test.SomeMethod(); assert(DoSomethingWasCalled(test.t_)); // access guts assert(DoSomeOtherThingWasCalled(test.t_)); // access guts } };

UnitTest :: Test2 का उपयोग TemplateUnderTest के शरीर तक पहुंच है और MockT की आंतरिक प्रतिलिपि पर बयानों की जांच कर सकता है।

एक टेम्पलेट एक प्रकार का तर्क लेता है और वर्चुअल फ़ंक्शन के बिना कई इंटरकनेक्ट किए गए टेम्पलेट बनाता है

इस मामले के लिए, मैं एक वास्तविक दुनिया उदाहरण देखूंगा : अतुल्यकालिक Google RPC ।

C ++ में, async gRPC में CallData नामक कुछ है, जो कि नाम से पता चलता है, RPC कॉल से संबंधित डेटा संग्रहीत करता है । CallData टेम्पलेट कई अलग-अलग प्रकार के RPC को संभाल सकता है। इसलिए यह स्वाभाविक है कि इसे खाके द्वारा ही लागू किया जाए।

एक सामान्य CallData दो प्रकार के तर्क स्वीकार करता है: अनुरोध और प्रतिक्रिया। यह इस तरह दिख सकता है:

 template <class Request, class Response> class CallData { grpc::ServerCompletionQueue *cq_; grpc::ServerContext context_; grpc::ServerAsyncResponseWriter<Response> responder_; // ... some more state public: using RequestType = Request; using ResponseType = Response; CallData(grpc::ServerCompletionQueue *q) : cq_(q), responder_(&context_) {} void HandleRequest(Request *req); // application-specific code Response *GetResponse(); // application-specific code };

CallData टेम्पलेट के लिए यूनिट टेस्ट में HandleRequest और HandleResponse के व्यवहार की जाँच होनी चाहिए। ये फ़ंक्शन कई सदस्य फ़ंक्शंस आमंत्रित करते हैं। इसलिए, उनके कॉल के स्वास्थ्य की पुष्टि करना कॉलडाटा के स्वास्थ्य के लिए सर्वोपरि है। हालांकि, वहाँ चालें हैं।

Grpc नाम स्थान से कुछ प्रकार आंतरिक रूप से बनाए जाते हैं और निर्माता के माध्यम से पारित नहीं होते हैं। उदाहरण के लिए ServerAsyncResponseWriter और ServerContext ।
grpc :: ServerCompletionQueue कंस्ट्रक्टर को एक तर्क के रूप में पारित किया जाता है, लेकिन इसका कोई आभासी कार्य नहीं है। केवल एक आभासी विध्वंसक।
grpc :: ServerContext आंतरिक रूप से बनाया गया है और इसमें कोई वर्चुअल फ़ंक्शन नहीं है।

सवाल यह है कि परीक्षणों में पूर्ण जीआरपीसी का उपयोग किए बिना कॉलडाटा का परीक्षण कैसे किया जाए? ServerCompletionQueue का अनुकरण कैसे करें? ServerAsyncResponseWriter का अनुकरण कैसे करें, जो स्वयं एक टेम्पलेट है? और इसी तरह ...

आभासी कार्यों के बिना, उपयोगकर्ता के व्यवहार को प्रतिस्थापित करना एक कठिन काम हो जाता है। हार्डकैप्ड प्रकार, जैसे कि grpc :: ServerAsyncResponseWriter, को मॉडलिंग नहीं किया जा सकता क्योंकि वे हैं, हम्म, हार्डकोड और कार्यान्वित नहीं।

उन्हें रचनाकार के तर्क के रूप में पारित करने में बहुत कम समझ है। यदि आप ऐसा करते हैं, तो भी इसका कोई मतलब नहीं हो सकता है, क्योंकि वे अंतिम वर्ग हो सकते हैं या बस वर्चुअल फ़ंक्शन नहीं हो सकते हैं।

तो हम क्या करें?

समाधान: लक्षण

एक सामान्य प्रकार (जैसा कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में किया जाता है) से विरासत में कस्टम व्यवहार एम्बेड करने के बजाय, टाइप करें। हम इसके लिए लक्षणों का उपयोग करते हैं। हम अलग-अलग तरीकों से लक्षणों में विशेषज्ञ हैं कि यह किस प्रकार का कोड है: एक उत्पादन कोड या एक इकाई परीक्षण कोड।

CallDataTraits पर विचार करें

 template <class CallData> class CallDataTraits { using ServerCompletionQueue = grpc::ServerCompletionQueue; using ServerContext = grpc::ServerContext; using ServerAsyncResponseWriter = grpc::ServerAsyncResponseWrite<typename CallData::ResponseType>; };

यह उत्पादन कोड के लिए उपयोग किए जाने वाले विशेषता के लिए मुख्य टेम्पलेट है। चलो इसे कॉलडैटमेटप्लेट में उपयोग करते हैं।

 /// Unit testable CallData template <class Request, class Response> class CallData { typename CallDataTraits<CallData>::ServerCompletionQueue *cq_; typename CallDataTraits<CallData>::ServerContext context_; typename CallDataTraits<CallData>::ServerAsyncResponseWriter responder_; // ... some more state public: using RequestType = Request; using ResponseType = Response; CallData(typename CallDataTraits::ServerCompletionQueue *q) : cq_(q), responder_(&context_) {} void HandleRequest(Request *req); // application-specific code Response *GetResponse(); // application-specific code };

ऊपर दिए गए कोड को देखते हुए, यह स्पष्ट है कि एप्लिकेशन कोड अभी भी grpc नाम स्थान से प्रकार का उपयोग करता है। हालाँकि, हम आसानी से डमी प्रकारों के साथ grpc प्रकारों को बदल सकते हैं। नीचे देखें।

 /// In unit test code struct TestRequest{}; struct TestResponse{}; struct MockServerCompletionQueue{}; struct MockServerContext{}; struct MockServerAsyncResponseWriter{}; /// We want to unit test this type. using CallDataUnderTest = CallData<TestRequest, TestResponse>; /// A specialization of CallDataTraits for unit testing purposes only. template <> class CallDataTraits<CallDataUnderTest> { using ServerCompletionQueue = MockServerCompletionQueue; using ServerContext = MockServerContext; using ServerAsyncResponseWriter = MockServerAsyncResponseWrite; }; MockServerCompletionQueue mock_queue; CallDataUnderTest cdut(&mock_queue); // Now injected with mock types.

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

आप सामग्री को कैसे पसंद करते हैं? टिप्पणी लिखिए। और खुले दरवाजे पर आपको देखने ;-)

यूनिट परीक्षण C ++ और मॉक इंजेक्शन पैटर्न का उपयोग कर लक्षण

टेम्पलेट कंस्ट्रक्टर में संदर्भ द्वारा एक प्रकार का तर्क और उसी प्रकार का ऑब्जेक्ट लेता है

टेम्पलेट एक प्रकार का तर्क लेता है। निर्माता तर्क की एक प्रति बनाता है या बस इसे स्वीकार नहीं करता है

एक टेम्पलेट एक प्रकार का तर्क लेता है और वर्चुअल फ़ंक्शन के बिना कई इंटरकनेक्ट किए गए टेम्पलेट बनाता है

समाधान: लक्षण

More articles: