I was working on writing tests for gnome-settings-daemon a week or so ago, and finally got blocked on being unable to set up upower/ConsoleKit/etc. the way I need them. Also, doing so needs root privileges, I don’t want my test suite to actually suspend my machine, and using the real service is generally not suitable for test suites that are supposed to run during “make check”, in jhbuild, and the like — these do not have the polkit privileges to do all that, and may not even have a system D-Bus running in the first place.
So I wrote a little test_upower.py helper, then realized that I need another one for systemd/ConsoleKit (for the “system idle” property), also looked at the mock polkit in udisks and finally sat down for two days to generalize this and do this properly.
The result is python-dbusmock, I just released the first tarball. With this you can easily create mock objects on D-Bus from any programming language with a D-Bus binding, or even from the shell.
The mock objects look like the real API (or at least the parts that you actually need), but they do not actually do anything (or only some action that you specify yourself). You can configure their state, behaviour and responses as you like in your test, without making any assumptions about the real system status.
When using a local system/session bus, you can do unit or integration testing without needing root privileges or disturbing a running system. The Python API offers some convenience functions like “start_session_bus()“ and “start_system_bus()“ for this, in a “DBusTestCase“ class (subclass of the standard “unittest.TestCase“).
Surprisingly I found very little precedence here. There is a Perl module, but that’s not particuarly helpful for test suites in C/Vala/Python. And there is Phil’s excellent Bendy Bus, but this has a different goal: If you want to thoroughly test a particular D-BUS service, such as ensuring that it does the right thing, doesn’t crash on bad input, etc., then Bendy Bus is for you (and python-dbusmock isn’t). However, it is too much overhead and rather inconvenient if you want to test a client-side program and just need a few system services around it which you want to set up in different states for each test.
You can use python-dbusmock with any programming language, as you can run the mocker as a normal program. The actual setup of the mock (adding objects, methods, properties, etc.) all happen via D-Bus methods on the “org.freedesktop.DBus.Mock“ interface. You just don’t have the convenience D-Bus launch API.
The simplest possible example is to create a mock upower with a single Suspend() method, which you can set up like this from Python:
import dbus
import dbusmock
class TestMyProgram(dbusmock.DBusTestCase):
[...]
def setUp(self):
self.p_mock = self.spawn_server('org.freedesktop.UPower',
'/org/freedesktop/UPower',
'org.freedesktop.UPower',
system_bus=True,
stdout=subprocess.PIPE)
# Get a proxy for the UPower object's Mock interface
self.dbus_upower_mock = dbus.Interface(self.dbus_con.get_object(
'org.freedesktop.UPower', '/org/freedesktop/UPower'),
'org.freedesktop.DBus.Mock')
self.dbus_upower_mock.AddMethod('', 'Suspend', '', '', '')
[...]
def test_suspend_on_idle(self):
# run your program in a way that should trigger one suspend call
# now check the log that we got one Suspend() call
self.assertRegex(self.p_mock.stdout.readline(), b'^[0-9.]+ Suspend$')
This doesn’t depend on Python, you can just as well run the mocker like this:
python3 -m dbusmock org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower
and then set up the mocks through D-Bus like
gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
-m org.freedesktop.DBus.Mock.AddMethod '' Suspend '' '' ''
If you use it with Python, you get access to the dbusmock.DBusTestCase class which provides some convenience functions to set up and tear down local private session and system buses. If you use it from another language, you have to call dbus-launch yourself.
Please see the README for some more details, pointers to documentation and examples.
Update: You can now install this via pip from PyPI or from the daily builds PPA.
Update 2: Adjusted blog entry for version 0.0.3 API, to avoid spreading now false information too far.
