fdo-mirrors/dbus
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/dbus/dbus.git synced 2025-12-20 18:30:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
dbus/test/test-utils.h

41 lines
1.8 KiB
C
Raw Normal View History

having a bad cvs add day apparently
2003-04-07 15:42:22 +00:00
#ifndef TEST_UTILS_H
#define TEST_UTILS_H
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
having a bad cvs add day apparently
2003-04-07 15:42:22 +00:00
#include <stdio.h>
#include <stdlib.h>
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
#include <dbus/dbus.h>
tests: always use libdbus-internal for main loop, never dbus-glib This gets rid of a potential circular dependency, which is annoying when bootstrapping. It is nice to have the regression tests use the shared libdbus, but we're about to make it possible to do that anyway, even though some of them use internal symbols. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2015-02-20 15:07:23 +00:00
#include <dbus/dbus-mainloop.h>
#include <dbus/dbus-internals.h>
typedef DBusLoop TestMainContext;
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
test-utils: Separate failable and non-failable functions test_object_try_whatever() now has libdbus-like OOM handling, while test_object_whatever() has GLib-like OOM handling. This is because an overwhelming majority of the callers of these functions either didn't check for OOM anyway, or checked for it but then aborted. In the uncommon case where we do care, we can use the _try_ version. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
2017-11-27 19:26:03 +00:00
_DBUS_GNUC_WARN_UNUSED_RESULT
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
TestMainContext *test_main_context_get (void);
test-utils: Separate failable and non-failable functions test_object_try_whatever() now has libdbus-like OOM handling, while test_object_whatever() has GLib-like OOM handling. This is because an overwhelming majority of the callers of these functions either didn't check for OOM anyway, or checked for it but then aborted. In the uncommon case where we do care, we can use the _try_ version. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
2017-11-27 19:26:03 +00:00
_DBUS_GNUC_WARN_UNUSED_RESULT
TestMainContext *test_main_context_try_get (void);
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
TestMainContext *test_main_context_ref (TestMainContext *ctx);
void test_main_context_unref (TestMainContext *ctx);
void test_main_context_iterate (TestMainContext *ctx,
dbus_bool_t may_block);
test-utils: Separate failable and non-failable functions test_object_try_whatever() now has libdbus-like OOM handling, while test_object_whatever() has GLib-like OOM handling. This is because an overwhelming majority of the callers of these functions either didn't check for OOM anyway, or checked for it but then aborted. In the uncommon case where we do care, we can use the _try_ version. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
2017-11-27 19:26:03 +00:00
_DBUS_GNUC_WARN_UNUSED_RESULT
dbus_bool_t test_connection_try_setup (TestMainContext *ctx,
DBusConnection *connection);
void test_connection_setup (TestMainContext *ctx,
having a bad cvs add day apparently
2003-04-07 15:42:22 +00:00
DBusConnection *connection);
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
void test_connection_shutdown (TestMainContext *ctx,
2003-04-07 Havoc Pennington <hp@redhat.com> * doc/dbus-specification.sgml: require that base service names start with ':' and that the base service is created/deleted as first and last things a connection does on the bus * bus/dispatch.c (check_existent_service_activation): lots more work on the activation test; it doesn't fully pass yet... * test/test-service.c (main): fix so we don't memleak the connection to the message bus (filter_func): accept a message asking us to exit
2003-04-07 23:28:16 +00:00
DBusConnection *connection);
having a bad cvs add day apparently
2003-04-07 15:42:22 +00:00
test-utils: Separate failable and non-failable functions test_object_try_whatever() now has libdbus-like OOM handling, while test_object_whatever() has GLib-like OOM handling. This is because an overwhelming majority of the callers of these functions either didn't check for OOM anyway, or checked for it but then aborted. In the uncommon case where we do care, we can use the _try_ version. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
2017-11-27 19:26:03 +00:00
_DBUS_GNUC_WARN_UNUSED_RESULT
dbus_bool_t test_server_try_setup (TestMainContext *ctx,
DBusServer *server);
void test_server_setup (TestMainContext *ctx,
Add test library functions for using DBusServer * test/test-utils.h, test/test-utils.c: Add functions which hook up a DBusServer to a DBusLoop, useful for test cases.
2008-05-30 10:33:18 -04:00
DBusServer *server);
Tests: allow dbus-glib to be replaced with use of libdbus-internal We only use dbus-glib for its main loop; within dbus, DBusLoop is available as an alternative, although it isn't thread-safe and isn't public API. For tests that otherwise only use libdbus public API, it's desirable to be able to avoid DBusLoop, so we can run them against an installed libdbus as an integration test. However, if we don't have dbus-glib, we're going to have to use an in-tree main loop, which might as well be DBusLoop. The major disadvantage of using dbus-glib is that it isn't safe to link both dbus-1 and dbus-internal at the same time. This is awkward for a future test case that wants to use _dbus_getsid() in dbus-daemon.c, but only on Windows (fd.o #54445). If we use the same API wrapper around both dbus-glib and DBusLoop, we can compile that test against dbus-glib or against DBusLoop, depending on the platform. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
2013-09-02 16:32:31 +01:00
void test_server_shutdown (TestMainContext *ctx,
Add test library functions for using DBusServer * test/test-utils.h, test/test-utils.c: Add functions which hook up a DBusServer to a DBusLoop, useful for test cases.
2008-05-30 10:33:18 -04:00
DBusServer *server);
Factor out some utility functions from test/dbus-daemon* In the process, make test_kill_pid() safer: do not try to terminate more than one pid, or the NULL handle. Also stop leaking the address_fd in spawn_dbus_daemon, a pre-existing bug that was spotted by Philip Withnall during review. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88810 Reviewed-by: Philip Withnall
2015-01-26 19:02:59 +00:00
void test_pending_call_store_reply (DBusPendingCall *pc,
void *data);
2003-04-07 Havoc Pennington <hp@redhat.com> * doc/dbus-specification.sgml: require that base service names start with ':' and that the base service is created/deleted as first and last things a connection does on the bus * bus/dispatch.c (check_existent_service_activation): lots more work on the activation test; it doesn't fully pass yet... * test/test-service.c (main): fix so we don't memleak the connection to the message bus (filter_func): accept a message asking us to exit
2003-04-07 23:28:16 +00:00
having a bad cvs add day apparently
2003-04-07 15:42:22 +00:00
#endif
Reference in a new issue Copy permalink