How to make automated tests for clients of D-Bus system service?
Simon McVittie
smcv at collabora.com
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:
> https://github.com/martinpitt/python-dbusmock
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.
smcv
More information about the dbus
mailing list