* to established concepts found in the other test frameworks (JUnit, NUnit,
* RUnit), which in turn is based on smalltalk unit testing concepts.
*
- * <variablelist>
- * <varlistentry>
- * <term>Test case</term>
- * <listitem>Tests (test methods) are grouped together with their
- * fixture into test cases.</listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>Fixture</term>
- * <listitem>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.</listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>Test suite</term>
- * <listitem>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.</listitem>
- * </varlistentry>
- * </variablelist>
+ * - 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
- * |[
+ * |[<!-- language="C" -->
* g_test_add_func ("/misc/assertions", test_assertions);
* ]|
* creates a test suite called "misc" with a single test case named
/**
* GTestTrapFlags:
* @G_TEST_TRAP_SILENCE_STDOUT: Redirect stdout of the test child to
- * <filename>/dev/null</filename> so it cannot be observed on the
- * console during test runs. The actual output is still captured
- * though to allow later tests with g_test_trap_assert_stdout().
+ * `/dev/null` so it cannot be observed on the console during test
+ * runs. The actual output is still captured though to allow later
+ * tests with g_test_trap_assert_stdout().
* @G_TEST_TRAP_SILENCE_STDERR: Redirect stderr of the test child to
- * <filename>/dev/null</filename> so it cannot be observed on the
- * console during test runs. The actual output is still captured
- * though to allow later tests with g_test_trap_assert_stderr().
+ * `/dev/null` so it cannot be observed on the console during test
+ * runs. The actual output is still captured though to allow later
+ * tests with g_test_trap_assert_stderr().
* @G_TEST_TRAP_INHERIT_STDIN: If this flag is given, stdin of the
* child process is shared with stdin of its parent process.
- * It is redirected to <filename>/dev/null</filename> otherwise.
+ * It is redirected to `/dev/null` otherwise.
*
* Test traps are guards around forked tests.
* These flags determine what traps to set.
* GTestSubprocessFlags:
* @G_TEST_SUBPROCESS_INHERIT_STDIN: If this flag is given, the child
* process will inherit the parent's stdin. Otherwise, the child's
- * stdin is redirected to <filename>/dev/null</filename>.
+ * stdin is redirected to `/dev/null`.
* @G_TEST_SUBPROCESS_INHERIT_STDOUT: If this flag is given, the child
* process will inherit the parent's stdout. Otherwise, the child's
* stdout will not be visible, but it will be captured to allow
* an error message is logged and the application is terminated.
*
* The macro can be turned off in final releases of code by defining
- * <envar>G_DISABLE_ASSERT</envar> when compiling the application.
+ * `G_DISABLE_ASSERT` when compiling the application.
*/
/**
* application is terminated.
*
* The macro can be turned off in final releases of code by defining
- * <envar>G_DISABLE_ASSERT</envar> when compiling the application.
+ * `G_DISABLE_ASSERT` when compiling the application.
*/
/**
* The advantage of this macro is that it can produce a message that
* includes the actual values of @s1 and @s2.
*
- * |[
+ * |[<!-- language="C" -->
* g_assert_cmpstr (mystring, ==, "fubar");
* ]|
*
* 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:
- * <variablelist>
- * <varlistentry>
- * <term><option>-l</option></term>
- * <listitem><para>
- * List test cases available in a test executable.
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>--seed=<replaceable>RANDOMSEED</replaceable></option></term>
- * <listitem><para>
- * Provide a random seed to reproduce test runs using random numbers.
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>--verbose</option></term>
- * <listitem><para>Run tests verbosely.</para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>-q</option>, <option>--quiet</option></term>
- * <listitem><para>Run tests quietly.</para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>-p <replaceable>TESTPATH</replaceable></option></term>
- * <listitem><para>
- * Execute all tests matching <replaceable>TESTPATH</replaceable>.
- * This can also be used to force a test to run that would otherwise
- * be skipped (ie, a test whose name contains "/subprocess").
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>-m {perf|slow|thorough|quick|undefined|no-undefined}</option></term>
- * <listitem><para>
- * Execute tests according to these test modes:
- * <variablelist>
- * <varlistentry>
- * <term>perf</term>
- * <listitem><para>
- * Performance tests, may take long and report results.
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>slow, thorough</term>
- * <listitem><para>
- * Slow and thorough tests, may take quite long and
- * maximize coverage.
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>quick</term>
- * <listitem><para>
- * Quick tests, should run really quickly and give good coverage.
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>undefined</term>
- * <listitem><para>
- * 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
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term>no-undefined</term>
- * <listitem><para>
- * Avoid tests for undefined behaviour
- * </para></listitem>
- * </varlistentry>
- * </variablelist>
- * </para></listitem>
- * </varlistentry>
- * <varlistentry>
- * <term><option>--debug-log</option></term>
- * <listitem><para>Debug test logging output.</para></listitem>
- * </varlistentry>
- * </variablelist>
+ *
+ * - <option>-l</option>: List test cases available in a test executable.
+ * - <option>--seed=SEED</option>: Provide a random seed to reproduce test
+ * runs using random numbers.
+ * - <option>--verbose</option>: Run tests verbosely.
+ * - <option>-q</option>, <option>--quiet</option>: Run tests quietly.
+ * - <option>-p PATH</option>: 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").
+ * - <option>-m {perf|slow|thorough|quick|undefined|no-undefined}</option>: Execute tests according to these test modes:
+ *
+ * <option>perf</option>: Performance tests, may take long and report results.
+ *
+ * <option>slow</option>, <option>thorough</option>: Slow and thorough tests, may take quite long and maximize coverage.
+ *
+ * <option>quick</option>: Quick tests, should run really quickly and give good coverage.
+ *
+ * <option>undefined</option>: 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
+ *
+ * <option>no-undefined</option>: Avoid tests for undefined behaviour
+ *
+ * - <option>--debug-log</option>: Debug test logging output.
*
* Since: 2.16
*/
* The forking parent process then asserts successful child program
* termination and validates child program outputs.
*
- * |[
+ * |[<!-- language="C" -->
* static void
* test_fork_patterns (void)
* {
* <literal>my_object_new(1000000)</literal> will abort with an error
* message.
*
- * |[
+ * |[<!-- language="C" -->
* static void
* test_create_large_object_subprocess (void)
* {
projects / platform / upstream / glib.git / blobdiff