Add undefined/no-undefined mode options to GTester
[platform/upstream/glib.git] / glib / gtestutils.c
index d2bf682..3406d43 100644 (file)
  * 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.
  */
 
 /**
@@ -489,6 +507,7 @@ static GTestConfig mutable_test_config_vars = {
   FALSE,        /* test_perf */
   FALSE,        /* test_verbose */
   FALSE,        /* test_quiet */
+  TRUE,         /* test_undefined */
 };
 const GTestConfig * const g_test_config_vars = &mutable_test_config_vars;
 
@@ -715,6 +734,10 @@ parse_args (gint    *argc_p,
               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;
@@ -763,6 +786,7 @@ parse_args (gint    *argc_p,
                   "  -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"
@@ -823,7 +847,7 @@ parse_args (gint    *argc_p,
  *       </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>
@@ -846,6 +870,20 @@ parse_args (gint    *argc_p,
  *               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>
@@ -1281,10 +1319,10 @@ g_test_run (void)
  * 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
@@ -1557,7 +1595,7 @@ g_test_queue_free (gpointer gfree_pointer)
  * @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