0

Currently I do it this way (pseudocode):

#include <boost/test/unit_test.hpp>
#include <string>

bool testingClient = true;

BOOST_AUTO_TEST_SUITE(ProtocolSchema)
BOOST_AUTO_TEST_CASE(server)
{
    testingClient = false;
    // start server listener
    FILE *client_stdout = popen((argv[0] + std::string(" --run_test=ProtocolSchema/client 2>&1")).c_str(), "r");
    for (1000ms)
    {
       // listen for ping, reply with a pong  
    }
    pclose(fl);
}

BOOST_AUTO_TEST_CASE(client)
{
    if (!testingClient)
        return;
    // send ping to the server
    // check that it replies with a pong
}
}

The idea is clear: boost::test runs tests sequentially, once it tries to run server, the server unit test flips testingClient this way next test simply doesn't do anything and exits. server test starts the same test executable with run_test arg set to run client test only. In the second process testingClient flag isn't flipped, this makes it actually run client test.

Is there a proper way to do this kind of client-server unit testing with boost::test? In my case all the test logging from client process are kind of lost: I'd need to fread them from client_stdout and then perhaps write it all to BOOST_MESSAGE?

Pavel P
  • 15,789
  • 11
  • 79
  • 128
  • Looks like you could definitely make use of [fixtures](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/tests_organization/fixtures.html). – Dan Mašek Mar 18 '17 at 02:12
  • We use them, but that won't help in my case. It has no relationship with starting separate processes (I cannot run them in the same process) – Pavel P Mar 19 '17 at 03:46

1 Answers1

0

As mentioned a fixture will help you:

  • setting up the server before the test
  • killing this server after the test

Setting up the server would mean that you start another thread in the fixture (keep track of that thread or any signalling letting you communicate with this thread). This thread should be alive for the duration of the test. In the fixture teardown, just signal the thread to exit.

I would avoid calling the same test module with different parameters, as you suggest, for various reasons:

  • the server is actually not a test: if you run the test module without eg. any parameter on the command line, then this server will run, which is something you want to avoid outside of tests
  • you have no/little control over the server lifetime, and it is difficult from one test to check that the server is actually running

Hope this helps

Raffi
  • 3,068
  • 31
  • 33