DrogonTest is a minimal testing framework built into drogon to enable easy asynchronous testing as well as synchronous ones. It is used for Drogon’s own unittests and integration tests. But could also be used for testing applications built with Drogon. The syntax of DrogonTest is inspired by both GTest and Catch2.

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

Basic testing

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.

  1. // Tell DrogonTest to generate `test::run()`. Only defined this in the main file
  2. #define DROGON_TEST_MAIN
  3. #include <drogon/drogon_test.h>
  4. int sum_all(int n)
  5. {
  6. int result = 1;
  7. for(int i=2;i<n;i++) result += i;
  8. return result;
  9. }
  10. DROGON_TEST(Sum)
  11. {
  12. CHECK(sum_all(1) == 1);
  13. CHECK(sum_all(2) == 3);
  14. CHECK(sum_all(3) == 6);
  15. }
  16. int main(int argc, char** argv)
  17. {
  18. return drogon::test::run(argc, argv);
  19. }

Compile and run… Well, it passed but there’s an obvious bug isn’t it. sum_all(0) 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. }

Now the test fails with:

  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:

  1. int sum_all(int n)
  2. {
  3. int result = 0;
  4. for(int i=1;i<n;i++) result += i;
  5. return result;
  6. }

Types of assertions

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.

action if fail/expression is true throws does not throw throws certain type
nothing CHECK CHECK_THROWS CHECK_NOTHROW CHECK_THROWS_AS
return REQUIRE REQUIRE_THROWS REQUIRE_NOTHROW REQUIRE_THROWS_AS
co_return CO_REQUIRE CO_REQUIRE_THROWS CO_REQUIRE_NOTHROW CO_REQUIRE_THROWS_AS
kill process MANDATE MANDATE_THROWS MANDATE_NOTHROW MANDATE_THROWS_AS

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. // CHECK(in.is_open() == true);
  7. // if(in.is_open() == false)
  8. // return;
  9. ...
  10. }

Likewise, CO_REQUIRE is like REQUIRE. But for coroutines. And MANDATE can be used when an operation failed and it modifies an unrecoverable global state. Which the only logical thing to do is to stop testing completely.

Asynchronous testing

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);
  11. CHECK(resp->getStatusCode == k200Ok);
  12. CHECK(resp->contentType() == CT_APPLICATION_JSON);
  13. });
  14. }

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.

  1. DROGON_TEST(RemoteAPITestCoro)
  2. {
  3. auto api_test = [TEST_CTX]() {
  4. auto client = HttpClient::newHttpClient("http://localhost:8848");
  5. auto req = HttpRequest::newHttpRequest();
  6. req->setPath("/");
  7. auto resp = co_await client->sendRequestCoro(req);
  8. CO_REQUIRE(resp != nullptr);
  9. CHECK(resp->getStatusCode == k200Ok);
  10. CHECK(resp->contentType() == CT_APPLICATION_JSON);
  11. };
  12. sync_wait(api_test());
  13. }

Starting Drogon’s event loop

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.

  1. int main()
  2. {
  3. std::promise<void> p1;
  4. 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. });
  11. // The future is only satisfied after the event loop started
  12. f1.get();
  13. int status = test::run(argc, argv);
  14. // Ask the event loop to shutdown and wait
  15. app().getLoop()->queueInLoop([]() { app().quit(); });
  16. thr.join();
  17. return status;
  18. }

CMake integration

Like most testing frameworks, DrogonTest can integrate itself into CMake. The ParseAndAddDrogonTests function adds tests it sees in the source file to CMake’s CTest framework.

  1. find_package(Drogon REQUIRED) # also loads ParseAndAddDrogonTests
  2. add_executable(mytest main.cpp)
  3. target_link_libraries(mytest PRIVATE Drogon::Drogon)
  4. ParseAndAddDrogonTests(mytest)

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

  1. make test
  2. Running tests...
  3. Test project path/to/your/test/build/
  4. Start 1: Sum
  5. 1/1 Test #1: Sum .................................... Passed 0.00 sec