* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the
- * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
- * Boston, MA 02111-1307, USA.
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
*/
#include "config.h"
* 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");
* ]|
*
static GSList **test_filename_free_list;
static guint test_run_forks = 0;
static guint test_run_count = 0;
+static guint test_skipped_count = 0;
static GTestResult test_run_success = G_TEST_RUN_FAILURE;
static gchar *test_run_msg = NULL;
static guint test_startup_skip_count = 0;
g_print ("Bail out!\n");
abort();
}
+ if (largs[0] == G_TEST_RUN_SKIPPED)
+ test_skipped_count++;
break;
case G_TEST_LOG_MIN_RESULT:
if (test_tap_log)
* 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
*/
* g_test_run_suite() or g_test_run() may only be called once
* in a program.
*
- * Returns: 0 on success
+ * 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 <literal>g_test_add_*</literal>
+ * 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.
+ *
+ * Returns: 0 on success, 1 on failure (assuming it returns at all),
+ * 77 if all tests were skipped with g_test_skip().
*
* Since: 2.16
*/
int
g_test_run (void)
{
- return g_test_run_suite (g_test_get_root());
+ if (g_test_run_suite (g_test_get_root()) != 0)
+ return 1;
+
+ if (test_run_count > 0 && test_run_count == test_skipped_count)
+ return 77;
+ else
+ return 0;
}
/**
* Execute the tests within @suite and all nested #GTestSuites.
* The test suites to be executed are filtered according to
* test path arguments (-p <replaceable>testpath</replaceable>)
- * as parsed by g_test_init().
+ * as parsed by g_test_init(). See the g_test_run() documentation
+ * for more information on the order that tests are run in.
+ *
* g_test_run_suite() or g_test_run() may only be called once
* in a program.
*
* 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)
* {
gboolean
g_test_trap_reached_timeout (void)
{
- return test_trap_last_status != G_TEST_STATUS_TIMED_OUT;
+ return test_trap_last_status == G_TEST_STATUS_TIMED_OUT;
}
void
*
* In order for this function to work in srcdir != builddir situations,
* the G_TEST_SRCDIR and G_TEST_BUILDDIR environment variables need to
- * have been defined. As of 2.38, this is done by the Makefile.decl
+ * have been defined. As of 2.38, this is done by the glib.mk
* included in GLib. Please ensure that your copy is up to date before
* using this function.
*
projects / platform / upstream / glib.git / blobdiff