GioTestDBus

一个辅助类，用于测试使用DBus而无需接触用户会话DBus的代码。

注意，GTestDBus修改用户的环境，调用setenv()。这不是线程安全的，所以应在创建线程之前完成所有GTestDBus调用，或者应该进行适当的锁定以确保没有对GTestDBus和其他线程之间共享的环境变量的访问冲突。

使用GTestDBus创建单元测试

由于通常我们只通过与DBus守护进程 Existing instance 运行DBus服务，因此我们通常不会激活尚未安装到目标系统的DBus服务。通过处理诸如运行私有的DBus守护进程和在可定制的位置（通常是源代码树中）查找未安装服务这样的低级任务，GTestDBus对象使我们能够更轻松地完成这项工作。

首先，您需要一个针对DBus守护进程的单独的服务描述文件。通常，tests目录下的services子目录是放置此文件的好地方。

服务文件应列出您的服务以及源代码树中未安装服务可执行文件的绝对路径。使用autotools，我们可以通过在服务目录中添加my-server.service.in等文件并使其通过configure处理来实现这一点。

[D-BUS Service]
Name=org.gtk.GDBus.Examples.ObjectManager
Exec=@abs_top_builddir@/gio/tests/gdbus-example-objectmanager-server

您还需要在测试固定方案中指示此服务目录，因此在编译测试用例时您需要传递路径。通常这通过autotools完成，添加一个预处理标志以编译测试，如下所示：

-DTEST_SERVICES=\""$(abs_top_builddir)/tests/services"\"

一旦您有一个局部于源代码树的本地服务定义文件，您可以使用GTestDBus脚手架来设置GTest固定方案。

DBus服务的测试固定方案的一个例子可以在以下位置找到： gdbus-test-fixture.c

请注意，这些示例仅涉及隔离服务的DBus方面。为了成功运行隔离的单例测试，您可能需要对测试固定方案进行一些额外的修改。例如；如果您的服务使用GSettings并且安装了一个模式，那么确保您的测试服务不在普通的安装位置加载模式非常重要（可能性是您的服务和模式文件尚未安装，或者更糟的是，模式文件的老版本位于安装位置）。

通常情况下，我们可以通过环境来绕过这些障碍。因为环境是由GTestDBus创建的D-Bus守护进程继承的，然后D-Bus守护进程再将其继承给它激活的任何服务，所以使用您的测试工具的设置例程是帮助沙盒化运行时环境的一个实用的地方。对于相当典型的GSettings情况，我们可以在上述fixture_setup()例程中将GSETTINGS_SCHEMA_DIR设置为包含您的模式在树目录中的目录来解决这个问题。

为了使此工作，必须先本地预编译GSettings模式。这可以通过在运行测试用例之前作为一个步骤本地编译模式来实现，autotools设置可能在包含模式的目录中执行以下操作：

    all-am:
            $(GLIB_COMPILE_SCHEMAS) .

    CLEANFILES += gschemas.compiled

自从：2.34