👨‍👩‍👧 🏷️ 😌 Boost.Asio और यूनिट परीक्षण पर अदरक 🔋 🖖🏼 🛁

सभी को नमस्कार! हमारे पिछले लेखों में से एक में , हमने बड़ी संख्या में कार्यस्थलों के साथ पेंटेस्ट संगठनों में इसके आगे के उपयोग के लिए "अदरक" बनाने के कार्य के हिस्से के रूप में अतुल्यकालिक पिंग के कार्य को लागू करने के बारे में बात की। आज हम इकाई परीक्षणों के साथ अपने अदरक (तर्क और नेटवर्क भाग) को कवर करने के बारे में बात करेंगे।

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

तब यह विचार आया कि किसी भी तरह से एक दूरस्थ मेजबान का अनुकरण करें और इसकी प्रतिक्रिया हमारे पिंजर से प्राप्त आदेशों के अनुसार करें। Boost.Asio से अतुल्यकालिक आदिम के कार्यान्वयन के आगे के अध्ययन पर, सेवाओं के परीक्षण कार्यान्वयन के साथ तैयार-किए गए प्राइमेट को पैरामीटर करने का विचार उत्पन्न हुआ जो हमारी आज्ञाओं का जवाब देंगे।

यह एक सरल सॉकेट आरेख है जो Boost.Asio में दिखता है। सादगी के लिए, हम केवल डेटा को जोड़ने, भेजने और प्राप्त करने के तरीकों पर विचार करेंगे।

पुस्तकालय कोड में, इस योजना का कार्यान्वयन निम्नानुसार है:

template <typename Protocol, typename StreamSocketService = stream_socket_service<Protocol> > class basic_stream_socket : public basic_socket<Protocol, StreamSocketService> { }

इस स्थिति में, सभी कॉल को बढ़ावा देने के लिए :: asio :: basic_stream_socket को StreamSocketService वर्ग में सौंपा गया है। यहाँ Boost.Asio लाइब्रेरी कोड का हिस्सा है जो इसे प्रदर्शित करता है:

  template <typename ConnectHandler> void async_connect(const endpoint_type& peer_endpoint, BOOST_ASIO_MOVE_ARG(ConnectHandler) handler) { ..... this->get_service().async_connect(this->get_implementation(), peer_endpoint, BOOST_ASIO_MOVE_CAST(ConnectHandler)(handler)); }

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

हमारे मामले में, जो एक संकलन समय निर्भरता इंजेक्शन से ज्यादा कुछ नहीं है, एक परीक्षण सॉकेट के लिए एक सरल आरेख इस तरह दिखाई देगा।

कोड में, परीक्षण और कार्य प्रधानता निम्नानुसार वर्णित हैं।

मानक आदिम

 class BoostPrimitives { public: typedef boost::asio::ip::tcp::socket TCPSocket; typedef boost::asio::ip::icmp::socket ICMPSocket; typedef boost::asio::ip::tcp::resolver Resolver; typedef boost::asio::deadline_timer Timer; };

परीक्षण आदिम

 class Primitives { public: typedef ba::basic_stream_socket < ba::ip::tcp, SocketService<ba::ip::tcp> > TCPSocket; typedef ba::basic_raw_socket < ba::ip::icmp, SocketService<ba::ip::icmp> > ICMPSocket; typedef ba::basic_deadline_timer < boost::posix_time::ptime, ba::time_traits<boost::posix_time::ptime>, TimerService < boost::posix_time::ptime, ba::time_traits<boost::posix_time::ptime> > > Timer; typedef ba::ip::basic_resolver < ba::ip::tcp, ResolverService<ba::ip::tcp> > Resolver; };

सॉकेट्स सर्विस, टिमरसेव्स और रेजोल्वर सर्विस - परीक्षण सेवाओं का कार्यान्वयन।

टाइमर और नाम रिज़ॉल्वर की प्राथमिकताओं, साथ ही साथ उनकी सेवाओं में एक समान संरचना है, इसलिए हम खुद को सॉकेट और उनकी सेवाओं के विवरण तक सीमित रखते हैं।

और इसलिए, एक सरलीकृत रूप में, अदरक के कामकाजी और परीक्षण कार्यान्वयन प्रस्तुत किए जाएंगे।

कोड में, यह निम्नानुसार दिखता है।

अदरक का क्रियान्वयन

 template<typename Traits> class PingerImpl { ..... //! Socket type typedef typename Traits::TCPSocket TCPSocket; ..... }

काम करने वाले संस्करण में अदरक

 class Pinger { //! Implementation type typedef PingerImpl<BoostPrimitives> Impl; .... private: //! Implementation std::auto_ptr<Impl> m_Impl; };

परीक्षण संस्करण में अदरक

 class BaseTest : boost::noncopyable { protected: //! Pinger implementation type typedef Net::PingerImpl<Test::Primitives> TestPinger; .... };

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

हम ICommand अमूर्तता का परिचय देते हैं, जो Boost.Asio प्राइमेटिव के तरीकों के समान तरीके प्रदान करेगा, और विशिष्ट कमांड को लागू करने वाली कक्षाएं बनाएँ (कनेक्ट क्लास नोड से कनेक्शन को लागू करेगा, प्राप्तकर्ता वर्ग डेटा प्राप्त करेगा, आदि)।

परीक्षणों का यूएमएल आरेख नीचे प्रस्तुत किया गया है।

टीम अमूर्तता

 //! Pinger test command interface class ICommand : boost::noncopyable { public: //! Command pointer typedef boost::shared_ptr<ICommand> Ptr; //! Error callback type typedef boost::function<void(const boost::system::error_code&)> ErrorCallback; //! Error and size callback typedef boost::function<void(const boost::system::error_code&, std::size_t)> ErrorAndSizeCallback; //! Resolver callback typedef boost::function<void(const boost::system::error_code&, boost::asio::ip::tcp::resolver::iterator)> ResolverCallback; public: ICommand(const Status::Enum status) : m_Status(status) {} //! Timer wait virtual void AsyncWait(ErrorCallback& callback, boost::asio::io_service& io); //! Async connect virtual void AsyncConnect(ErrorCallback& callback, boost::asio::io_service& io); //! Async receive virtual void AsyncReceive(ErrorAndSizeCallback& callback, const std::vector<char>& sended, const boost::asio::mutable_buffer& buffer, boost::asio::io_service& io); //! Async resolve virtual void AsyncResolve(ResolverCallback& callback, boost::asio::io_service& io); //! Dtor virtual ~ICommand() {} protected: Status::Enum m_Status; };

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

कनेक्शन कमांड कार्यान्वयन उदाहरण

 void Connect::AsyncConnect(ErrorCallback& callback, boost::asio::io_service& io) { if (m_Status != Status::Pending) { io.post(boost::bind(callback, m_Code)); callback = ErrorCallback(); } }

डिफ़ॉल्ट कार्यान्वयन रिपोर्ट करता है कि कमांड बदले में नहीं निकाली गई थी:

 void ICommand::AsyncConnect(ErrorCallback& /*callback*/, boost::asio::io_service& /*io*/) { assert(false); }

हमें एक वर्ग की भी आवश्यकता है - एक परीक्षण मामला जो कमांड कतार के साथ काम करने के लिए तरीके प्रदान करता है और पुष्टि करता है कि परीक्षण पूरा होने के बाद कतार में कोई कमांड नहीं बचा है।

आदेश पंक्ति में "परीक्षण केस" का कार्यान्वयन

 //! Test fixture class Fixture { //! Commands list typedef std::list<ICommand::Ptr> Commands; public: Fixture(); ~Fixture(); static void Push(ICommand* cmd); static ICommand::Ptr Pop(); private: static Commands s_Commands; }; Fixture::Commands Fixture::s_Commands; Fixture::Fixture() { assert(s_Commands.empty()); // ,       - } Fixture::~Fixture() { assert(s_Commands.empty()); //      } void Fixture::Push(ICommand* cmd) { s_Commands.push_back(ICommand::Ptr(cmd)); } ICommand::Ptr Fixture::Pop() { assert(!s_Commands.empty()); const ICommand::Ptr result = s_Commands.front(); s_Commands.pop_front(); return result; }

परीक्षण सेवा कार्यान्वयन का हिस्सा

 template<typename T> void async_connect(implementation_type& /*impl*/, const endpoint& /*ep*/, const T& callback) { m_ConnectCallback = callback; Fixture::Pop()->AsyncConnect(m_ConnectCallback, m_Service); //   }

इकाई परीक्षण Google ढांचे पर लिखे गए हैं, यहाँ ICMP पिंग के लिए एक परीक्षण कार्यान्वयन का एक उदाहरण है:

 class BaseTest : boost::noncopyable { protected: //! Pinger implementation type typedef Net::PingerImpl<Test::Primitives> TestPinger; BaseTest() { m_Pinger.reset(new TestPinger(boost::bind(&BaseTest::Callback, this, _1, _2))); } virtual ~BaseTest() { m_Pinger->AddRequest(m_Command); while (m_Pinger->IsActive()) boost::this_thread::interruptible_wait(100); } template<typename T> void Cmd(const Status::Enum status) { m_Fixture.Push(new T(status)); } template<typename T, typename A> void Cmd(const Status::Enum status, const A& arg) { m_Fixture.Push(new T(status, arg)); } void Callback(const Net::PingCommand& /*cmd*/, const Net::PingResult& /*rslt*/) { //     ,     } Fixture m_Fixture; std::auto_ptr<TestPinger> m_Pinger; Net::PingCommand m_Command; }; //        //   -   ,    . class ICMPTest : public testing::Test, public BaseTest { }; TEST(ICMPTest, ICMPSuccess) { m_Command.m_HostName = "ptsecurity.ru"; Cmd<Resolve>(Status::Success, m_Command.m_HostName); //  IP   Cmd<Wait>(Status::Pending); //   ,  Status::Pending – ,      Cmd<Receive>(Status::Success); //        m_Command.m_Flags = SCANMGR_PING_ICMP; //        BaseTest } TEST(ICMPTest, ICMPFail) { m_Command.m_HostName = "ptsecurity.ru"; Cmd<Resolve>(Status::Success, m_Command.m_HostName); //  IP   Cmd<Wait>(Status::Success); //   ,  Status::Success – ,     Cmd<Receive>(Status::Pending); //      m_Command.m_Flags = SCANMGR_PING_ICMP; //        BaseTest }

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

आरेख में, Google मॉक का उपयोग करके TestLogic वर्ग बनाया गया था। इस मामले में, तर्क परीक्षण उन तरीकों और तर्कों का क्रम निर्धारित करते हैं जिनके साथ उन्हें कुछ इनपुट मापदंडों के साथ बुलाया जाएगा।

परीक्षण तर्क कार्यान्वयन

 class TestLogic : public Net::PingerLogic { public: TestLogic(const Net::PingCommand& cmd, const Net::Pinger::Callback& callback) : Net::PingerLogic(cmd, callback) { } MOCK_METHOD1(InitPorts, void (const std::string& ports)); MOCK_METHOD1(ResolveIP, bool (const std::string& name)); MOCK_METHOD1(StartResolveNameByIp, void (unsigned long ip)); MOCK_METHOD1(StartResolveIpByName, void (const std::string& name)); MOCK_METHOD1(StartTCPPing, void (std::size_t timeout)); MOCK_METHOD1(StartICMPPing, void (std::size_t timeout)); MOCK_METHOD1(StartGetNetBiosName, void (const std::string& name)); MOCK_METHOD0(Cancel, void ()); };

इकाई परीक्षण उदाहरणों की एक जोड़ी

 TEST(Logic, Start) { const std::string host = "ptsecurity.ru"; EXPECT_CALL(*m_Logic, InitPorts(g_TargetPorts)).Times(Exactly(1)); EXPECT_CALL(*m_Logic, ResolveIP(host)).Times(Exactly(1)).WillOnce(Return(true)); EXPECT_CALL(*m_Logic, StartResolveIpByName(host)).Times(Exactly(1)); m_Logic->OnStart(); } TEST(Logic, ResolveIp) { static const unsigned long ip = 0x10101010; EXPECT_CALL(*m_Logic, StartResolveNameByIp(ip)).Times(Exactly(1)); EXPECT_CALL(*m_Logic, StartICMPPing(1)).Times(Exactly(1)); EXPECT_CALL(*m_Logic, StartTCPPing(1)).Times(Exactly(1)); m_Logic->OnIpResolved(ip); }

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

यहाँ से हम निष्कर्ष निकाल सकते हैं:

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

आपके ध्यान के लिए आप सभी का धन्यवाद!

सर्गेई कर्णखोव ( CLRN ) द्वारा पोस्ट किया गया।

Boost.Asio और यूनिट परीक्षण पर अदरक

More articles: