Runs all tests under the toplevel suite which can be retrieved
g_test_get_root(). Similar to
g_test_run_suite(), the test
cases to be run are filtered according to test path arguments
-p testpath and
-s testpath) as parsed by
g_test_run() may only be called once in a program.
In general, the tests and sub-suites within each suite are run in
the order in which they are defined. However, note that prior to
GLib 2.36, there was a bug in the
functions which caused them to create multiple suites with the same
name, meaning that if you created tests “/foo/simple”,
“/bar/simple”, and “/foo/using-bar” in that order, they would get
run in that order (since
g_test_run() would run the first “/foo”
suite, then the “/bar” suite, then the second “/foo” suite). As of
2.36, this bug is fixed, and adding the tests in that order would
result in a running order of “/foo/simple”, “/foo/using-bar”,
“/bar/simple”. If this new ordering is sub-optimal (because it puts
more-complicated tests before simpler ones, making it harder to
figure out exactly what has failed), you can fix it by changing the
test paths to group tests by suite in a way that will result in the
desired running order. Eg, “/simple/foo”, “/simple/bar”, “/complex/foo-using-bar”.
However, you should never make the actual result of a test depend
on the order that tests are run in. If you need to ensure that some
particular code runs before or after a given test case, use
g_test_add(), which lets you specify setup and teardown functions.
If all tests are skipped or marked as incomplete (expected failures), this function will return 0 if producing TAP output, or 77 (treated as “skip test” by Automake) otherwise.