Boost.Asio Pinger and Unit Testing

Hello! In one of our previous articles, we talked about the implementation of the function of asynchronous ping as part of the task of creating a "pinger" for its further use in pentest organizations with a large number of workstations. Today we will talk about the coverage of our pinger (logic and network part) with unit tests.

It is clear that the need to write code that will be tested, disciplines and helps to plan the architecture more intelligently. However, the first thought about covering the asynchronous code on Boost.Asio with unit tests was something like this: “What ?! It is absolutely impossible! How can I write a test based on the node’s network accessibility? ”

Then an idea appeared to somehow emulate a remote node and its responses to commands received from our pinger. Further study of the implementation of asynchronous primitives from Boost.Asio gave rise to the idea of ​​parameterizing ready-made primitives with test implementations of services that will respond to our commands.
')
This is what a simplified socket diagram in Boost.Asio looks like. For simplicity, we will consider only the methods of connecting, sending and receiving data.



In the library code, the implementation of this scheme is as follows:

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

In this case, all calls in boost :: asio :: basic_stream_socket are delegated to the class StreamSocketService. Here is a part of the Boost.Asio library code that demonstrates this:

  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)); } 

In other words, the socket class itself is, in fact, just a wrapper that is parameterized by protocol and service types; a good example of static polymorphism. So, in order to “replace” the implementation of socket methods, we need to specify our service implementation as a parameter of the socket template. This is what this socket hierarchy would look like when using dynamic polymorphism with the addition of a test service.



In our case, which is nothing more than Compile time dependency injection , the simplified diagram for the test socket will look like this.



In the code, test and working primitives are described as follows.



SocketService, TimerService and ResolverService are test service implementations.

The primitives of the timer and resolver of names, as well as their services have a similar structure, so we limit ourselves to the description of sockets and their services.

And this is how the working and test implementations of the pinger will be presented in a simplified form.



In the code, it looks like this.




So, we have access to individual operations of primitives. Now you need to understand how to use them to organize a test case covering the ping process. We can represent this process (ping a node) as a sequence of commands executed via the Boost.Asio library. We need a certain queue of commands that will be filled in during the initialization of the test script and empty during the execution of the ping. Here is a state diagram describing test performance.



We introduce the ICommand abstraction, which will provide methods similar to the methods of the Boost.Asio primitives, and create classes for the implementation of specific commands (the Connect class will implement connections to the node, the Receive class - receive data, etc.).

UML-diagram of the tests is presented below.




At the same time, methods that are not provided by a specific command will contain test statements: this way we will be able to control the sequence of execution of commands.


The "default" implementation reports that the command is not extracted in turn:

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

We also need a class - a test case that provides methods for working with the command queue and verifies that there are no teams left in the queue after the test has been completed.



Unit tests are written on the Google framework , here is an example of the implementation of a test for ICMP ping:

 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 } 

So, with testing the network part of the pinger, everything is clear: you only need to describe the sequence of commands for each of the possible ping scenarios. Recall that the pinger logic contains several virtual methods that are redefined in the PingerImpl class. Thus, we managed to untie the logic from the network part.



In the diagram, the TestLogic class is created using a google mock . In this case, logic tests determine the sequence of methods and arguments with which they will be invoked, with certain input parameters.



As a result, the task was successfully solved, the benefit of Boost.Asio is an excellent framework, perfectly suited for such purposes. In addition, as usual, in the process of covering with unit tests, several serious bugs were revealed :) Of course, we managed to save many hours of manual testing and debugging of the code. From the moment the pinger code was introduced into the product, it revealed only one minor bug related to inattention when writing the code, which means that the time to develop and write unit tests was not wasted!

From here we can draw conclusions:

• Unit testing is a very useful thing, unit tests should ideally cover all the code.
• Practically any problem of covering a code with tests is solved! It is only necessary to break the tested code into a sufficient number of abstractions.

Thank you all for your attention!

Author: Sergey Karnaukhov ( CLRN ).