Using Google Test for a program that uses Glib event loop

Question

I am writing a program to be run as a background service in Linux. I am writing it in C++ and using glibmm for event loop.

The only user interface the program will have is a D-Bus service.

I'd like to write some tests for it using Google Test. What I am planning is that while the program itself instantiates a D-Bus service, the test code would also instantiate a D-Bus client and initiate actions in the program via D-Bus calls.

The test cases I have in mind would mostly be something like "Call a D-Bus method and use asserts to see that some method is called with certain arguments." One important outcome of the tests would also be simply seeing that the tests don't crash.

I can see severel options for how to write the program and the tests. For example, one could, in theory, create the event loop either once in main() or separately in each test case. If it is created only once, it could still theoretically be either run continuously or started and stopped in each test case. I tried googling for examples, but only found something in which Qt was used instead of Glib. I don't know if that makes a significant difference.

Is there any existing wisdom about a case like this? What is worth trying and what is not? Or am I intending to use Google Test for something it is not meant for?

Answer 1

You may find it easier to build your server as a library, with a C++ interface, and test that using normal unit tests. The shim layer which exposes that over D-Bus could then be very thin and not require extensive testing.

If you do want to test the D-Bus service, it’s probably easier to compile it into the test program (so that the D-Bus client and server are running in the same process) so that you don’t have to worry about handling the server as a subprocess (which adds extra complexity and makes debugging failures a lot trickier).

Then run the D-Bus service in one thread and the D-Bus client + test code in another thread, so that they can’t block on each other.

It’s generally safer to destroy the main context and main loop (plus any other context) after each test, to ensure you don’t have state left from one test to affect the next. In particular, problems are commonly caused by the GSources left by one test in a GMainContext continuing to fire in the next one.

I can’t comment on how this translates into use of Google Test. It’s certainly possible to do it with the normal GLib unit testing API.