D-Bus unit tests

Ralf Habacker ralf.habacker at freenet.de
Wed Nov 12 01:45:01 PST 2014

Am 12.11.2014 um 10:32 schrieb Thomas Sondergaard:
> Hi,
> I have a bunch of unit tests that use D-Bus that are run by jenkins.
> On Linux, jenkins starts an Xvnc display for me, on Windows I just
> have the jenkins users local display. I would like to be able to run
> my tests in parallel, and to that end I want each started test
> executable to start its own dbus-daemon, but I want child processes
> started by the test executable to use that same D-Bus daemon. I'm
> Using QtDBus (Qt 4.8, hopefully 5.x soon).
> My thinking is that I need to do something like this:
> qputenv("DBUS_SESSION_BUS_ADDRESS", "autolaunch:");
> QDBusConnection::sessionBus(); // Trigger connect
> getDBusAddress(QDBusConnection::sessionBus()));
> Unfortunately, I don't know how to implement getDBusAddress(), but the
> autolaunch: mechanism also doesn't work as I expect. If another
> process has already been started with autolaunch: I get connected to
> it's dbus-daemon (on RHEL7 linux, haven't tried on Windows). Btw, this
> seems inconsistent with
> http://dbus.freedesktop.org/doc/dbus-launch.1.html which says
> "Whenever an autolaunch occurs, the application that had to start a
> new bus will be in its own little world". It is however consistent
> with
> http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch.
According to the mentioned spec on windows you may set

qputenv("DBUS_SESSION_BUS_ADDRESS", "autolaunch:<key>");

with a unique string for <key> before running each test app. The dbus
library will then check for the existance of a related dbus-damon and
will autostart one, if not present.

Not sure yet if there is a "dbus-daemon build in" way to shut down such
a running dbus-daemon after test finish.


More information about the dbus mailing list