## GTestDBus

GTestDBus — D-Bus testing helper

## Synopsis

    #include <gio/gio.h>

                        GTestDBus;
    enum                GTestDBusFlags;
    GTestDBus *         g_test_dbus_new                     (GTestDBusFlags flags);
    GTestDBusFlags      g_test_dbus_get_flags               (GTestDBus *self);
    const gchar *       g_test_dbus_get_bus_address         (GTestDBus *self);
    void                g_test_dbus_add_service_dir         (GTestDBus *self,
                                                             const gchar *path);
    void                g_test_dbus_up                      (GTestDBus *self);
    void                g_test_dbus_stop                    (GTestDBus *self);
    void                g_test_dbus_down                    (GTestDBus *self);
    void                g_test_dbus_unset                   (void);

## Object Hierarchy

      GObject
       +----GTestDBus

      GFlags
       +----GTestDBusFlags

## Properties

      "flags"                    GTestDBusFlags        : Read / Write / Construct Only

## Description

A helper class for testing code which uses D-Bus without touching the user's session bus.

### Creating unit tests using GTestDBus

Testing of D-Bus services can be tricky because normally we only ever run D-Bus services over an existing instance of the D-Bus daemon thus we usually don't activate D-Bus services that are not yet installed into the target system. The GTestDBus object makes this easier for us by taking care of the lower level tasks such as running a private D-Bus daemon and looking up uninstalled services in customizable locations, typically in your source code tree.

The first thing you will need is a separate service description file for the D-Bus daemon. Typically a 'services' subdirectory of your 'tests' directory is a good place to put this file.

The service file should list your service along with an absolute path to the uninstalled service executable in your source tree. Using autotools we would achieve this by adding a file such as 'my-server.service.in' in the services directory and have it processed by configure.

    1
    2
    3

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

You will also need to indicate this service directory in your test fixtures, so you will need to pass the path while compiling your test cases. Typically this is done with autotools with an added preprocessor flag specified to compile your tests such as:

    1

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

Once you have a service definition file which is local to your source tree, you can proceed to setup a GTest fixture using the GTestDBus scaffolding.

Example 27. Test Fixture for D-Bus services

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95

    #include "gdbus-object-manager-example/gdbus-example-objectmanager-generated.h"

    /* ---------------------------------------------------------------------------------------------------- */

    /* The fixture contains a GTestDBus object and
     * a proxy to the service we're going to be testing.
     */
    typedef struct {
      GTestDBus *dbus;
      GDBusObjectManager *manager;
    } TestFixture;

    static void
    fixture_setup (TestFixture *fixture, gconstpointer unused)
    {
      GError *error = NULL;

      /* Create the global dbus-daemon for this test suite
       */
      fixture->dbus = g_test_dbus_new (G_TEST_DBUS_NONE);

      /* Add the private directory with our in-tree service files,
       * TEST_SERVICES is defined by the build system to point
       * to the right directory.
       */
      g_test_dbus_add_service_dir (fixture->dbus, TEST_SERVICES);

      /* Start the private D-Bus daemon
       */
      g_test_dbus_up (fixture->dbus);

      /* Create the proxy that we're going to test
       */
      fixture->manager =
        example_object_manager_client_new_for_bus_sync (G_BUS_TYPE_SESSION,
                                                        G_DBUS_OBJECT_MANAGER_CLIENT_FLAGS_NONE,
                                                        "org.gtk.GDBus.Examples.ObjectManager",
                                                        "/example/Animals",
                                                        NULL, /* GCancellable */
                                                        &error);
      if (fixture->manager == NULL)
        g_error ("Error getting object manager client: %s", error->message);
    }

    static void
    fixture_teardown (TestFixture *fixture, gconstpointer unused)
    {
      /* Tear down the proxy
       */
      if (fixture->manager)
        g_object_unref (fixture->manager);

      /* Stop the private D-Bus daemon
       */
      g_test_dbus_down (fixture->dbus);
      g_object_unref (fixture->dbus);
    }

    /* The gdbus-example-objectmanager-server exports 10 objects,
     * to test the server has actually activated, let's ensure
     * that 10 objects exist.
     */
    static void
    test_gtest_dbus (TestFixture *fixture, gconstpointer unused)
    {
      GList *objects;

      objects = g_dbus_object_manager_get_objects (fixture->manager);

      g_assert_cmpint (g_list_length (objects), ==, 10);
      g_list_free_full (objects, g_object_unref);
    }

    int
    main (int   argc,
          char *argv[])
    {
      g_test_init (&argc, &argv, NULL);

      /* This test simply ensures that we can bring the GTestDBus up and down a hand
       * full of times in a row, each time successfully activating the in-tree service
       */
      g_test_add ("/GTestDBus/Cycle1", TestFixture, NULL,
              fixture_setup, test_gtest_dbus, fixture_teardown);
      g_test_add ("/GTestDBus/Cycle2", TestFixture, NULL,
              fixture_setup, test_gtest_dbus, fixture_teardown);
      g_test_add ("/GTestDBus/Cycle3", TestFixture, NULL,
              fixture_setup, test_gtest_dbus, fixture_teardown);
      g_test_add ("/GTestDBus/Cycle4", TestFixture, NULL,
              fixture_setup, test_gtest_dbus, fixture_teardown);
      g_test_add ("/GTestDBus/Cycle5", TestFixture, NULL,
              fixture_setup, test_gtest_dbus, fixture_teardown);

      return g_test_run ();
    }

Note that these examples only deal with isolating the D-Bus aspect of your service. To successfully run isolated unit tests on your service you may need some additional modifications to your test case fixture. For example; if your service uses GSettings and installs a schema then it is important that your test service not load the schema in the ordinary installed location (chances are that your service and schema files are not yet installed, or worse; there is an older version of the schema file sitting in the install location).

Most of the time we can work around these obstacles using the environment. Since the environment is inherited by the D-Bus daemon created by GTestDBus and then in turn inherited by any services the D-Bus daemon activates, using the setup routine for your fixture is a practical place to help sandbox your runtime environment. For the rather typical GSettings case we can work around this by setting GSETTINGS_SCHEMA_DIR to the in tree directory holding your schemas in the above `fixture_setup()` routine.

The GSettings schemas need to be locally pre-compiled for this to work. This can be achieved by compiling the schemas locally as a step before running test cases, an autotools setup might do the following in the directory holding schemas:

    1
    2
    3
    4

    all-am:
            $(GLIB_COMPILE_SCHEMAS) .

    CLEANFILES += gschemas.compiled

## Details

### GTestDBus

    typedef struct _GTestDBus GTestDBus;

The GTestDBus structure contains only private data and should only be accessed using the provided API.

Since 2.34

### enum GTestDBusFlags

    typedef enum {
      G_TEST_DBUS_NONE = 0
    } GTestDBusFlags;

Flags to define future GTestDBus behaviour.

`G_TEST_DBUS_NONE` | No flags.

Since 2.34

### g_test_dbus_new ()

    GTestDBus *         g_test_dbus_new                     (GTestDBusFlags flags);

Create a new GTestDBus object.

`flags` : | a GTestDBusFlags
Returns : | a new GTestDBus. [transfer full]

### g_test_dbus_get_flags ()

    GTestDBusFlags      g_test_dbus_get_flags               (GTestDBus *self);

Gets the flags of the GTestDBus object.

`self` : | a GTestDBus
Returns : | the value of "flags" property

### g_test_dbus_get_bus_address ()

    const gchar *       g_test_dbus_get_bus_address         (GTestDBus *self);

Get the address on which dbus-daemon is running. if `g_test_dbus_up()` has not been called yet, `NULL` is returned. This can be used with `g_dbus_connection_new_for_address()`

`self` : | a GTestDBus
Returns : | the address of the bus, or `NULL`.

### g_test_dbus_add_service_dir ()

    void                g_test_dbus_add_service_dir         (GTestDBus *self,
                                                             const gchar *path);

Add a path where dbus-daemon will lookup for .services files. This can't be called after `g_test_dbus_up()`.

`self` : | a GTestDBus
`path` : | path to a directory containing .service files

### g_test_dbus_up ()

    void                g_test_dbus_up                      (GTestDBus *self);

Start a dbus-daemon instance and set DBUS_SESSION_BUS_ADDRESS. After this call, it is safe for unit tests to start sending messages on the session bus.

If this function is called from setup callback of `g_test_add()`, `g_test_dbus_down()` must be called in its teardown callback.

If this function is called from unit test's `main()`, then `g_test_dbus_down()` must be called after `g_test_run()`.

`self` : | a GTestDBus

### g_test_dbus_stop ()

    void                g_test_dbus_stop                    (GTestDBus *self);

Stop the session bus started by `g_test_dbus_up()`.

Unlike `g_test_dbus_down()`, this won't verify the GDBusConnection singleton returned by `g_bus_get()` or `g_bus_get_sync()` is destroyed. Unit tests wanting to verify behaviour after the session bus has been stopped can use this function but should still call `g_test_dbus_down()` when done.

`self` : | a GTestDBus

### g_test_dbus_down ()

    void                g_test_dbus_down                    (GTestDBus *self);

Stop the session bus started by `g_test_dbus_up()`.

This will wait for the singleton returned by `g_bus_get()` or `g_bus_get_sync()` is destroyed. This is done to ensure that the next unit test won't get a leaked singleton from this test.

`self` : | a GTestDBus

### g_test_dbus_unset ()

    void                g_test_dbus_unset                   (void);

Unset DISPLAY and DBUS_SESSION_BUS_ADDRESS env variables to ensure the test won't use user's session bus.

This is useful for unit tests that want to verify behaviour when no session bus is running. It is not necessary to call this if unit test already calls `g_test_dbus_up()` before acquiring the session bus.

## Property Details

### The `"flags"` property

      "flags"                    GTestDBusFlags        : Read / Write / Construct Only

GTestDBusFlags specifying the behaviour of the dbus session

Since 2.34