* g_test_quick:
*
* Returns %TRUE if tests are run in quick mode.
+ * Exactly one of g_test_quick() and g_test_slow() is active in any run;
+ * there is no "medium speed".
*
* Returns: %TRUE if in quick mode
*/
* g_test_slow:
*
* Returns %TRUE if tests are run in slow mode.
+ * Exactly one of g_test_quick() and g_test_slow() is active in any run;
+ * there is no "medium speed".
*
- * Returns: %TRUE if in slow mode
+ * Returns: the opposite of g_test_quick()
*/
/**
* g_test_thorough:
*
- * Returns %TRUE if tests are run in thorough mode.
+ * Returns %TRUE if tests are run in thorough mode, equivalent to
+ * g_test_slow().
*
- * Returns: %TRUE if in thorough mode
+ * Returns: the same thing as g_test_slow()
*/
/**
*/
/**
+ * g_test_undefined:
+ *
+ * Returns %TRUE if tests may provoke assertions and other formally-undefined
+ * behaviour under g_test_trap_fork(), to verify that appropriate warnings
+ * are given. It can be useful to turn this off if running tests under
+ * valgrind.
+ *
+ * Returns: %TRUE if tests may provoke programming errors
+ */
+
+/**
* g_test_verbose:
*
* Returns %TRUE if tests are run in verbose mode.
+ * The default is neither g_test_verbose() nor g_test_quiet().
*
* Returns: %TRUE if in verbose mode
*/
* g_test_quiet:
*
* Returns %TRUE if tests are run in quiet mode.
+ * The default is neither g_test_verbose() nor g_test_quiet().
*
- * Returns: %TRUE if in quied mode
+ * Returns: %TRUE if in quiet mode
*/
/**
* an error message is logged and the application is terminated.
*
* The macro can be turned off in final releases of code by defining
- * #G_DISABLE_ASSERT when compiling the application.
+ * <envar>G_DISABLE_ASSERT</envar> when compiling the application.
*/
/**
* application is terminated.
*
* The macro can be turned off in final releases of code by defining
- * #G_DISABLE_ASSERT when compiling the application.
+ * <envar>G_DISABLE_ASSERT</envar> when compiling the application.
*/
/**
FALSE, /* test_perf */
FALSE, /* test_verbose */
FALSE, /* test_quiet */
+ TRUE, /* test_undefined */
};
const GTestConfig * const g_test_config_vars = &mutable_test_config_vars;
mutable_test_config_vars.test_quick = TRUE;
mutable_test_config_vars.test_perf = FALSE;
}
+ else if (strcmp (mode, "undefined") == 0)
+ mutable_test_config_vars.test_undefined = TRUE;
+ else if (strcmp (mode, "no-undefined") == 0)
+ mutable_test_config_vars.test_undefined = FALSE;
else
g_error ("unknown test mode: -m %s", mode);
argv[i] = NULL;
" -p TESTPATH execute all tests matching TESTPATH\n"
" -s TESTPATH skip all tests matching TESTPATH\n"
" -m {perf|slow|thorough|quick} Execute tests according modes\n"
+ " -m {undefined|no-undefined} Execute tests according modes\n"
" --debug-log debug test logging output\n"
" -k, --keep-going gtester-specific argument\n"
" --GTestLogFD=N gtester-specific argument\n"
* </para></listitem>
* </varlistentry>
* <varlistentry>
- * <term><option>-m {perf|slow|thorough|quick}</option></term>
+ * <term><option>-m {perf|slow|thorough|quick|undefined|no-undefined}</option></term>
* <listitem><para>
* execute tests according to these test modes:
* <variablelist>
* 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_fork() 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>
* Create a new #GTestCase, named @test_name, this API is fairly
* low level, calling g_test_add() or g_test_add_func() is preferable.
* When this test is executed, a fixture structure of size @data_size
- * will be allocated and filled with 0s. Then data_setup() is called
+ * will be allocated and filled with 0s. Then @data_setup is called
* to initialize the fixture. After fixture setup, the actual test
- * function data_test() is called. Once the test run completed, the
- * fixture structure is torn down by calling data_teardown() and
+ * function @data_test is called. Once the test run completed, the
+ * fixture structure is torn down by calling @data_teardown and
* after that the memory is released.
*
* Splitting up a test run into fixture setup, test function and
* @destroy_func: Destroy callback for teardown phase.
* @destroy_data: Destroy callback data.
*
- * This function enqueus a callback @destroy_func() to be executed
+ * This function enqueus a callback @destroy_func to be executed
* during the next test case teardown phase. This is most useful
* to auto destruct allocted test resources at the end of a test run.
* Resources are released in reverse queue order, that means enqueueing