diff --git a/python-python-dbusmock.changes b/python-python-dbusmock.changes index 954a8bc..55ab5a0 100644 --- a/python-python-dbusmock.changes +++ b/python-python-dbusmock.changes @@ -1,3 +1,14 @@ +------------------------------------------------------------------- +Wed Jan 9 22:19:11 UTC 2019 - Jan Engelhardt + +- Use noun phrase in summary. Trim description, it is not a manual. + +------------------------------------------------------------------- +Mon Jan 7 11:19:02 UTC 2019 - bjorn.lie@gmail.com + +- Update URL to new home: + * https://github.com/martinpitt/python-dbusmock + ------------------------------------------------------------------- Mon Jan 7 10:42:02 UTC 2019 - Tomáš Chvátal diff --git a/python-python-dbusmock.spec b/python-python-dbusmock.spec index dfa780f..330b8a3 100644 --- a/python-python-dbusmock.spec +++ b/python-python-dbusmock.spec @@ -20,10 +20,10 @@ Name: python-python-dbusmock Version: 0.18.1 Release: 0 -Summary: Mock D-Bus objects +Summary: Python library for creating mock D-Bus objects License: LGPL-3.0-or-later Group: Development/Languages/Python -URL: https://launchpad.net/python-dbusmock +URL: https://github.com/martinpitt/python-dbusmock Source: https://files.pythonhosted.org/packages/source/p/python-dbusmock/python-dbusmock-%{version}.tar.gz BuildRequires: %{python_module dbus-python} BuildRequires: %{python_module devel} @@ -41,43 +41,11 @@ BuildArch: noarch %python_subpackages %description -With this program/Python library you can easily create mock objects on D-Bus. +With this program/Python library, one can create mock objects on D-Bus. This is useful for writing tests for software which talks to D-Bus services such as upower, systemd, logind, gnome-session or others, and it is hard (or impossible without root privileges) to set the state of the real services -to what you expect in your tests. - -Suppose you want to write tests for gnome-settings-daemon's power plugin, or -another program that talks to upower. You want to verify that after the -configured idle time the program suspends the machine. So your program calls -``org.freedesktop.UPower.Suspend()`` on the system D-Bus. - -Now, your test suite should not really talk to the actual system D-Bus and the -real upower; a ``make check`` that suspends your machine will not be considered -very friendly by most people, and if you want to run this in continuous -integration test servers or package build environments, chances are that your -process does not have the privilege to suspend, or there is no system bus or -upower to begin with. Likewise, there is no way for an user process to -forcefully set the system/seat idle flag in logind, so your -tests cannot set up the expected test environment on the real daemon. - -That's where mock objects come into play: They 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``). - -You can use this with any programming language, as you can run the mocker as a -normal program. The actual setup of the mock (adding objects, methods, -properties, and signals) all happen via D-Bus methods on the -``org.freedesktop.DBus.Mock`` interface. You just don't have the convenience -D-Bus launch API that way. +to what one may expect in tests. %prep %setup -q -n python-dbusmock-%{version}