You don’t have to use DrogonTest for your application. Use whatever you are comfortable with. But it is an option.

Let’s start with a simple example. You have a synchronous function that computes the sum of natural numbers up to a given value. And you want to test it for correctness.

Compile and run… Well, it passed but there’s an obvious bug isn’t it. should have been 0. We can add that to our test

  1. DROGON_TEST(Sum)
  2. {
  3.     CHECK(sum_all(0) == 0);
  4.     CHECK(sum_all(1) == 1);
  5.     CHECK(sum_all(2) == 3);
  6.     CHECK(sum_all(3) == 6);
  7. }
  1. In test case Sum
  2. ↳ /path/to/your/test/main.cc:47  FAILED:
  3.   CHECK(sum_all(0) == 0)
  4. With expansion
  5.   1 == 0

Notice the framework printed the test that failed and the actual value at both ends of the expression. Allows us to see what’s going on immediately. And the solution is simple:

DrogonTest comes with a variety of assertions and actions. The basic CHECK() simply checks if the expression evaluates to true. If not, it prints to console. CHECK_THROWS() checks if the expression throws an exception. If it didn’t, print to console. etc.. On the other hand REQUIRE() checks if a expression is true. Then return if not, preventing expressions after the test being executed.

Let’s try a slightly practical example. Let’s say you’re testing if the content of a file is what you’re expecting. There’s no point to further test if the program failed to open the file. So, we can use REQUIRE to shorten and reduce duplicated code.

  1. DROGON_TEST(TestContent)
  2. {
  3.     std::ifstream in("data.txt");
  4.     REQUIRE(in.is_open());
  5.     // Instead of
  6.     // if(in.is_open() == false)
  9.     ...
  10. }

Drogon is a asynchronous web framework. It only follows DrogonTest supports testing asynchronous functions. DrogonTest tracks the testing context through the TEST_CTX variable. Simply capture the variable by value. For example, testing if a remote API is successful and returns a JSON.

  1. DROGON_TEST(RemoteAPITest)
  2. {
  3.     auto client = HttpClient::newHttpClient("http://localhost:8848");
  4.     auto req = HttpRequest::newHttpRequest();
  5.     req->setPath("/");
  6.     client->sendRequest(req, [TEST_CTX](ReqResult res, const HttpResponsePtr& resp) {
  7.         // There's nothing we can do if the request didn't reach the server
  8.         // or the server generated garbage.
  9.         REQUIRE(res == ReqResult::Ok);
  10.         REQUIRE(resp != nullptr);
  12.         CHECK(resp->getStatusCode == k200Ok);
  13.         CHECK(resp->contentType() == CT_APPLICATION_JSON);
  14.     });
  15. }

Coroutines have to be wrapped inside AsyncTask or called through sync_wait due to no native support of coroutines and C++14/17 compatibility in the testing framework.

Some tests need Drogon’s event loop running. For example, unless specified, HTTP clients runs on Drogon’s global event loop. The following boilerplate handles many edge cases and guarantees the event loop is running before any test starts.

  2.     std::promise<void> p1;
  3.     std::future<void> f1 = p1.get_future();
  5.     // Start the main loop on another thread
  6.     std::thread thr([&]() {
  7.         // Queues the promise to be fulfilled after starting the loop
  8.         app().getLoop()->queueInLoop([&p1]() { p1.set_value(); });
  9.         app().run();
  10.     });
  12.     // The future is only satisfied after the event loop started
  13.     f1.get();
  14.     int status = test::run(argc, argv);
  16.     // Ask the event loop to shutdown and wait
  17.     app().getLoop()->queueInLoop([]() { app().quit(); });
  18.     thr.join();
  19.     return status;
  20. }
  1. find_package(Drogon REQUIRED) # also loads ParseAndAddDrogonTests
  2. add_executable(mytest main.cpp)
  3. ParseAndAddDrogonTests(mytest)

Now the test could be ran through build system (Makefile in this case).