When using TAP we want every single line to be one of the following:
- a valid TAP clause
- a comment
- a blank line
Typical explicit test logs are single line comments, but in some cases
we might end up printing debug messages from libraries, and those may
contain multiple lines. When that happens, we break the TAP and fail the
test in conditions entirely outside of our control.
One option to avoid outright failure is to always prepend each line of a
messge with `#`, to ensure that the whole thing is considered a comment.
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()` or an existing `gsize`
variable), so that they use `g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it
In particular, this fixes an overflow within `g_bytes_new()`, identified
as GHSL-2021-045 by GHSL team member Kevin Backhouse.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319
AddressSanitizer detects memory leaks, NULL parameters where only a
non-NULL parameter is expected, and other suspicious behaviour, so if
we try to test that sort of thing we can expect it to fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I found myself wanting to know the test that is currently being run,
where e.g. __func__ would be inconvenient to use, because e.g. the place
the string was needed was not in the test case function. Using __func__
also relies on the test function itself containing the whole path, while
loosing the "/" information that is part of the test path.
They extend the behavior of, respectively, -p and -s options of the
glib test framework
Currently test suite are only run for one level under -p path, for
example, testfilemonitor -p /monitor would execute the following tests:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
With the --run-prefix the sub-test suite file will be executed:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
The --skip-prefix and run-prefix seems symmetrical, but there is a
difference with skip towards run:
--skip-prefix will use a prefix while --run-prefix only work for a valid test path.
For example and for the following test family:
/monitor/atomic-replace
/monitor/file-changes
/monitor/dir-monitor
/monitor/dir-not-existent
/monitor/cross-dir-moves
/monitor/file/hard-links
while --run-prefix /mon will not execute anything, --skip-prefix /mon
will skip all of these tests.
See #2238 which references this change.
The macro wrapper to `g_assertion_message_cmpstrv()` makes sure that
neither array is `NULL`, so there’s no need for a second `NULL` check.
Additionally, this check happens after the arrays have already been
dereferenced, at which point the program would have crashed if the
arrays were `NULL`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1436406, #1436407
We can’t do anything differently based on whether removing a file fails.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1354857
Improve formatting, and clarify that the same *type* of test fixture can
be reused, not the same specific instance of a test fixture.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #250
It seems a bit unhelpful to list every single `g_assert_*()` macro, to
rephrase the documentation to use globs instead.
Add a missing word below.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is for use in testing POSIX-style functions like `rmdir()`, which
return an integer < 0 on failure, and return their error information in
`errno`.
The new macro prints `errno` and `g_strerror (errno)` on failure.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These squash various warnings from `scan-build`. None of them are
legitimate bugs, but some of them do improve code readability a bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
Since we transitioned from Bugzilla to GitLab, we have two forms of bug
references in the GLib source code: old (but still relevant) Bugzilla
links, and newer GitLab links. We can’t use a single base for the two,
so have to either build incorrect URIs, or provide the full URI in
g_test_bug().
It’s always seemed a bit of an over-optimisation to provide the bug base
separately from the bug ID, so relax the assertions and documentation
around g_test_bug_base() so that g_test_bug() can be used on its own.
The old usage patterns are still supported unchanged.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_test_trap_fork() is deprecated, but it’s still tested in the GLib
tests. If we don’t set the coredump rlimit to 0 to prevent coredumps,
the test for it creates a coredump (which is expected). On systems with
systemd-coredump, that causes systemd-coredump to spawn and process the
coredump for a while. That slows down the tests, and results in spurious
coredump lists in the system logs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #436
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
This is a new function along the same lines as g_test_bug(): to allow
developers to annotate unit tests with information about the test (what
it tests, how it tests it) for future developers to read and learn from.
It will also output this summary as a comment in the test’s TAP output,
which might clarify test results.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1450
Only disable TAP output if the `--GTestLogFD` argument is passed to the
test, which is passed in by the (deprecated) gtester harness, and
shouldn’t ever have been passed in by anything else.
Also disable it when running a subprocess, using `--GTestSubprocess`,
since users commonly strictly check the stdout and stderr of test
subprocesses.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1619
Add warnings about their deprecation everywhere. The tools will continue
to work until we break API, but will be less well maintained. You should
use TAP for communicating test results to the test harness provided by
your build system or CI system instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1441
The -p option is documented, and can be used to select and repeat
test-cases. This is particularly useful when debugging a single
failure among a large number of test-cases, or when debugging a
test-case that you suspect influences another test-case by leaking
global state.
Until now, -p was only supported with GLib's default (GLib-specific)
textual output format, and not with the standardized TAP format that
we are now encouraging. If we are considering making TAP the new default
(see glib#1619) it should get feature-equivalence with the current
default.
Because -p allows test-cases to be re-ordered and repeated, and an entry
in the test_paths list can match any number of test-cases (including
zero), we don't know ahead of time how many test-cases we are going to
run. TAP allows the "plan" to be deferred to the end, exactly to support
situations like this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The undocumented --GTestSkipCount option is internal to the deprecated
gtester tool and rather obscure, but it's straightforward to support
by making G_TEST_LOG_SKIP_CASE produce TAP output similar to what already
happened when we emitted G_TEST_LOG_STOP_CASE with result
G_TEST_RUN_SKIPPED. I might as well do that while I'm looking at the
interaction between the --tap, -p and -s options.
Signed-off-by: Simon McVittie <smcv@collabora.com>
glib/gtestutils.c: In function ‘g_test_build_filename_va’:
glib/gtestutils.c:3865:49: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Werror=sign-compare]
for (num_path_segments = 2; num_path_segments < G_N_ELEMENTS (pathv); num_path_segments++)
^
It would be nice if docs.c eventually went away — it’s more maintainable
for documentation comments to be next to the definition of the symbols
they document.
Move a few from docs.c, based on what I’ve been modifying recently.
The documentation comments are unchanged apart from fixing an argument
name for G_ALIGNOF.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The subprocess needs to access the test_log_fd. If the file descriptors
are not left open, functions such as g_test_message may stomp on file
descriptors open by the subprocess and cause bad behavior of the test.
(Tweaked by Philip Withnall <bugzilla@tecnocode.co.uk> to fix review
comments.)
We’re about to drop autotools support. Rather than keep the .mk files
around in master indefinitely, link to the versions in the glib-2-58
branch (the last stable release of GLib which supports building with
autotools) in readiness for dropping the .mk files from master.
Any future fixes to these files can happen on the glib-2-58 branch. The
links should work forever (as long as we use GitLab).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a new G_TEST_OPTIONS_ISOLATE_XDG_DIRS option for g_test_init() which
automatically creates a temporary set of XDG directories, and a
temporary home directory, and overrides the g_get_user_data_dir() (etc.)
functions for the duration of the unit test with the temporary values.
This is intended to better isolate unit tests from the user’s actual
data and home directory. It works with g_test_subprocess(), but does not
work with subprocesses spawned manually by the test — each unit test’s
code will need to be amended to correctly set the XDG_* environment
variables in the environment of any spawned subprocess.
“Why not solve that by setting the XDG environment variables for the
whole unit test process tree?” I hear you say. Setting environment
variables is not thread safe and they would need to be re-set for each
unit test, once worker threads have potentially been spawned.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
In order to make some guarantees in an upcoming commit that test path
components won’t clash with file system names used by GLib, add a
restriction that test path components cannot start with a dot.
This is an API break, but one which anyone is unlikely to have hit. If
it is an issue, we can relax the restriction to be a warning.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
Seems a bit odd to have the documentation comment miles from what it’s
actually documenting.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/538
This is along the same lines as g_assert_cmpstr(), but for variants.
Based on a patch by Guillaume Desmottes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1191
Synchronize access to random number generator `test_run_rand` with
a lock to ensure that `g_test_rand_*` family of functions is
thread-safe.
The reseeding taking place between test case runs is intentionally left
unsynchronized. It is an error to continue using random number generator
after test case has already finished running. Lack of synchronization
here will make such erroneous use readily apparent with thread
sanitizer.
When running a test as a subprocess and matching its output, it’s very
annoying for GLib to tell you that the output didn’t match your pattern,
*but not actually say what the output was*. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If a test is marked with g_test_incomplete(), then it is expected to
fail, so when it fails the test executable should still exit 0
(or possibly 77, if all tests are either skipped or incomplete).
Signed-off-by: Simon McVittie <smcv@collabora.com>
