diff --git a/glib/gtestutils.c b/glib/gtestutils.c
index 4d8dbb84d..7279eb78f 100644
--- a/glib/gtestutils.c
+++ b/glib/gtestutils.c
@@ -67,27 +67,19 @@
* to established concepts found in the other test frameworks (JUnit, NUnit,
* RUnit), which in turn is based on smalltalk unit testing concepts.
*
- *
- *
- * Test case
- * Tests (test methods) are grouped together with their
- * fixture into test cases.
- *
- *
- * Fixture
- * A test fixture consists of fixture data and setup and
- * teardown methods to establish the environment for the test
- * functions. We use fresh fixtures, i.e. fixtures are newly set
- * up and torn down around each test invocation to avoid dependencies
- * between tests.
- *
- *
- * Test suite
- * Test cases can be grouped into test suites, to allow
- * subsets of the available tests to be run. Test suites can be
- * grouped into other test suites as well.
- *
- *
+ * - Test case: Tests (test methods) are grouped together with their
+ * fixture into test cases.
+ *
+ * - Fixture: A test fixture consists of fixture data and setup and
+ * teardown methods to establish the environment for the test
+ * functions. We use fresh fixtures, i.e. fixtures are newly set
+ * up and torn down around each test invocation to avoid dependencies
+ * between tests.
+ *
+ * - Test suite: Test cases can be grouped into test suites, to allow
+ * subsets of the available tests to be run. Test suites can be
+ * grouped into other test suites as well.
+ *
* The API is designed to handle creation and registration of test suites
* and test cases implicitly. A simple call like
* |[
@@ -1024,82 +1016,32 @@ parse_args (gint *argc_p,
* Initialize the GLib testing framework, e.g. by seeding the
* test random number generator, the name for g_get_prgname()
* and parsing test related command line args.
+ *
* So far, the following arguments are understood:
- *
- *
- *
- *
- * List test cases available in a test executable.
- *
- *
- *
- *
- *
- * Provide a random seed to reproduce test runs using random numbers.
- *
- *
- *
- *
- * Run tests verbosely.
- *
- *
- * ,
- * Run tests quietly.
- *
- *
- *
- *
- * Execute all tests matching TESTPATH.
- * This can also be used to force a test to run that would otherwise
- * be skipped (ie, a test whose name contains "/subprocess").
- *
- *
- *
- *
- *
- * Execute tests according to these test modes:
- *
- *
- * perf
- *
- * Performance tests, may take long and report results.
- *
- *
- *
- * slow, thorough
- *
- * Slow and thorough tests, may take quite long and
- * maximize coverage.
- *
- *
- *
- * quick
- *
- * Quick tests, should run really quickly and give good coverage.
- *
- *
- *
- * undefined
- *
- * Tests for undefined behaviour, may provoke programming errors
- * under g_test_trap_subprocess() or g_test_expect_messages() to check
- * that appropriate assertions or warnings are given
- *
- *
- *
- * no-undefined
- *
- * Avoid tests for undefined behaviour
- *
- *
- *
- *
- *
- *
- *
- * Debug test logging output.
- *
- *
+ *
+ * - : List test cases available in a test executable.
+ * - : Provide a random seed to reproduce test
+ * runs using random numbers.
+ * - : Run tests verbosely.
+ * - , : Run tests quietly.
+ * - : Execute all tests matching the given path.
+ * This can also be used to force a test to run that would otherwise
+ * be skipped (ie, a test whose name contains "/subprocess").
+ * - : Execute tests according to these test modes:
+ *
+ * : Performance tests, may take long and report results.
+ *
+ * , : Slow and thorough tests, may take quite long and maximize coverage.
+ *
+ * : Quick tests, should run really quickly and give good coverage.
+ *
+ * : Tests for undefined behaviour, may provoke programming errors
+ * under g_test_trap_subprocess() or g_test_expect_messages() to check
+ * that appropriate assertions or warnings are given
+ *
+ * : Avoid tests for undefined behaviour
+ *
+ * - : Debug test logging output.
*
* Since: 2.16
*/