How to make automated tests for clients of D-Bus system service?

Simon McVittie smcv at
Tue Feb 6 12:31:10 UTC 2018

On Tue, 06 Feb 2018 at 11:58:39 +0100, Bastien Nocera wrote:
> On Tue, 2018-02-06 at 11:57 +0100, Miroslav Kravec wrote:
> > How do I make following testing environment/setup:
> > 
> > * create "fake" system service with hardcoded, or generated, answers
> > to method calls,
> > * run "fake" system service without root access,
> This should be all you need:

Or if you want a little more detail than that, the standard procedure is:

* Run a dbus-daemon that you will pretend is the system bus, and capture
  its address (use the --print-address option)
* Put a mock implementation of your system service on that bus (write it
  however you like, but python-dbusmock is one option)
* Run your client with the environment variable DBUS_SYSTEM_BUS_ADDRESS
  set to the address where your fake system bus is listening

This is a lot like the procedure for testing session bus clients, but
with fake system services and a fake system bus instead of their session
bus counterparts.

If you're using GDBus, look at GTestDBus for inspiration (but you don't
necessarily want to *use* GTestDBus, because it has some design issues
around the lifetimes of the singleton shared bus connections vs. the
lifetime of a test fixture).

If you're using libdbus, (a) consider doing something else, or (b) take
a look at test/test-utils-glib.[ch] or tools/dbus-run-session.c in dbus
for inspiration.


More information about the dbus mailing list