Lines Matching +refs:test +refs:with +refs:testsuite
8 messages, propagate fatal failures, reuse and speed up your test fixtures, and
9 use various flags with your tests.
115 are fine with making the predicate slower in the success case, you can supply a
178 with [`EXPECT_THAT`](reference/assertions.md#EXPECT_THAT) to do more string
238 a method of the test fixture class. The one constraint is that assertions that
243 initialize return object of type 'bool' with an rvalue of type 'void'"` or
260 call `abort` and crash the entire test executable, or put the fatal assertion in
266 called from a constructor or destructor does not terminate the current test, as
272 ## Skipping test execution
274 Related to the assertions `SUCCEED()` and `FAIL()`, you can prevent further test
275 execution at runtime with the `GTEST_SKIP()` macro. This is useful when you need
276 to check for preconditions of the system under test during runtime and skip
279 `GTEST_SKIP()` can be used in individual test cases or in the `SetUp()` methods
285 GTEST_SKIP() << "Skipping single test";
302 As with assertion macros, you can stream a custom message into `GTEST_SKIP()`.
306 When a test assertion such as `EXPECT_EQ` fails, googletest prints the argument
389 corruption, security holes, or worse. Hence it is vitally important to test that
393 _death tests_. More generally, any test that checks that a program terminates
394 (except by throwing an exception) in an expected fashion is also a death test.
401 If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see
410 To write a death test, simply use one of the macros inside your test function.
415 // This death test uses a compound statement.
434 * calling `Foo(5)` causes the process to die with the given error message,
436 exit with exit code 0, and
437 * calling `KillProcess()` kills the process with signal `SIGKILL`.
439 The test function body may contain other assertions and statements as well, if
442 Note that a death test only cares about three things:
451 will **not** cause the death test to fail, as googletest assertions don't abort
458 **test suite** (not test) `*DeathTest` when it contains a death test, as
462 If a test fixture class is shared by normal tests and death tests, you can use
472 // normal test
476 // death test
530 The reason for the two death test styles has to do with thread safety. Due to
531 well-known problems with forking in the presence of threads, death tests should
539 1. A warning is emitted if multiple threads are running when a death test is
541 2. Test suites with a name ending in "DeathTest" are run before all other
547 It's perfectly fine to create threads inside a death test statement; they are
552 The "threadsafe" death test style was introduced in order to help mitigate the
554 test execution time (potentially dramatically so) for improved thread safety.
564 or in individual tests. Recall that flags are saved before running each test and
576 // This test is run in the "threadsafe" style:
581 // This test is run in the "fast" style:
590 exception, the death test is considered to have failed. Some googletest macros
596 in the parent process. In particular, if you release memory in a death test,
600 1. try not to free memory in a death test;
604 Due to an implementation detail, you cannot place multiple death test assertions
605 on the same line; otherwise, compilation will fail with an unobvious error
609 test, thread problems such as deadlock are still possible in the presence of
610 handlers registered with `pthread_atfork(3)`.
615 Note: If you want to put a series of test assertions in a subroutine to check
623 If a test sub-routine is called from several places, when an assertion inside it
640 line number in arguments, which is useful for writing test helpers. The effect
702 when they fail they only abort the _current function_, not the entire test. For
703 example, the following test will segfault:
716 // in Subroutine() to abort the entire test.
729 #### Asserting on Subroutines with an exception
753 As shown above, if your test calls a subroutine that has an `ASSERT_*` failure
754 in it, the test will continue after the subroutine returns. This may not be what
784 assertion in the current test has suffered a fatal failure. This allows
809 If `HasFatalFailure()` is used outside of `TEST()` , `TEST_F()` , or a test
816 Similarly, `HasNonfatalFailure()` returns `true` if the current test has at
818 test has at least one failure of either kind.
822 In your test code, you can call `RecordProperty("key", value)` to log additional
826 test
847 > needs to be prefixed with `::testing::Test::` if used outside of the
848 > `TEST` body and the test fixture class.
849 > * *`key`* must be a valid XML attribute name, and cannot conflict with the
852 > * Calling `RecordProperty()` outside of the lifespan of a test is allowed.
853 > If it's called outside of a test but between a test suite's
855 > attributed to the XML element for the test suite. If it's called outside
856 > of all test suites (e.g. in a test environment), it will be attributed to
861 googletest creates a new test fixture object for each test in order to make
863 that are expensive to set up, making the one-copy-per-test model prohibitively
867 single resource copy. So, in addition to per-test set-up/tear-down, googletest
868 also supports per-test-suite set-up/tear-down. To use it:
870 1. In your test fixture class (say `FooTest` ), declare as `static` some member
872 2. Outside your test fixture class (typically just below it), define those
874 3. In the same test fixture class, define a `static void SetUpTestSuite()`
875 function (remember not to spell it as **`SetupTestSuite`** with a small
880 *first test* in the `FooTest` test suite (i.e. before creating the first
881 `FooTest` object), and calls `TearDownTestSuite()` after running the *last test*
885 Remember that the test order is undefined, so your code can't depend on a test
888 state to its original value before passing control to the next test.
890 Note that `SetUpTestSuite()` may be called multiple times for a test fixture
896 Here's an example of per-test-suite set-up and tear-down:
901 // Per-test-suite set-up.
902 // Called before the first test in this test suite.
911 // Per-test-suite tear-down.
912 // Called after the last test in this test suite.
919 // You can define per-test set-up logic as usual.
922 // You can define per-test tear-down logic as usual.
942 sometimes be necessary to declare it public, such as when using it with
947 Just as you can do set-up and tear-down at the test level and the test suite
948 level, you can also do it at the test program level. Here's how.
950 First, you subclass the `::testing::Environment` class to define a test
966 Then, you register an instance of your environment class with googletest by
976 always calls `TearDown()` with each environment object, regardless of whether or
1005 *Value-parameterized tests* allow you to test your code with different
1006 parameters without writing multiple copies of the same test. This is useful in a
1012 * You want to test different implementations of an OO interface.
1013 * You want to test your code over various inputs (a.k.a. data-driven testing).
1029 NOTE: If your test fixture defines `SetUpTestSuite()` or `TearDownTestSuite()`
1037 // To access the test parameter, call GetParam() from class
1051 Then, use the `TEST_P` macro to define as many test patterns using this fixture
1057 // Inside a test, access the test parameter with the GetParam() method
1069 test suite with any set of parameters you want. GoogleTest defines a number of
1070 functions for generating test parameters—see details at
1075 test suite each with parameter values `"meeny"`, `"miny"`, and `"moe"` using the
1089 instantiation of the test suite. The next argument is the name of the test
1093 You can instantiate a test pattern more than once, so to distinguish different
1095 actual test suite name. Remember to pick unique prefixes for different
1108 with parameter values `"cat"` and `"dog"` using the
1124 given test suite, whether their definitions come before or *after* the
1128 `INSTANTIATE_TEST_SUITE_P` causes a failing test in test suite
1129 `GoogleTestVerification`. If you have a test suite where that omission is not an
1131 where the list of test cases is dynamic and may be empty, then this check can be
1132 suppressed by tagging the test suite:
1141 …master/googletest/samples/sample8_unittest.cc "Parameterized Test example with multiple parameters"
1150 the test parameter) that all implementations of the interface are expected to
1156 1. Put the definition of the parameterized test fixture class (e.g. `FooTest`)
1164 contains `foo_param_test.cc`. You can instantiate the same abstract test suite
1170 specify a function or functor that generates custom test name suffixes based on
1171 the test parameters. The function should accept one argument of type
1174 `testing::PrintToStringParamName` is a builtin test suffix generator that
1179 NOTE: test names must be non-empty, unique, and may only contain ASCII
1181 [should not contain underscores](faq.md#why-should-test-suite-names-and-test-names-not-contain-unde…
1195 Providing a custom functor allows for more control over test parameter name
1227 verify it. In both cases, you want the same test logic repeated for different
1230 While you can write one `TEST` or `TEST_F` for each type you want to test (and
1231 you may even factor the test logic into a function template that you invoke from
1235 *Typed tests* allow you to repeat the same test logic over a list of types. You
1236 only need to write the test logic once, although you must know the type list
1253 Next, associate a list of types with the test suite, which will be repeated for
1265 Then, use `TYPED_TEST()` instead of `TEST_F()` to define a typed test for this
1266 test suite. You can repeat this as many times as you want:
1270 // Inside a test, refer to the special name TypeParam to get the type
1297 you to know the list of types ahead of time. Instead, you can define the test
1298 logic first and instantiate it with different type lists later. You can even
1304 just instantiate the test suite with their type to verify that it conforms to
1308 First, define a fixture class template, as we did with typed tests:
1317 Next, declare that you will define a type-parameterized test suite:
1323 Then, use `TYPED_TEST_P()` to define a type-parameterized test. You can repeat
1328 // Inside a test, refer to TypeParam to get the type parameter.
1336 Now the tricky part: you need to register all test patterns using the
1338 argument of the macro is the test suite name; the rest are the names of the
1339 tests in this test suite:
1346 Finally, you are free to instantiate the pattern with the types you want. If you
1357 actual test suite name. Remember to pick unique prefixes for different
1373 black-box testing principle, most of the time you should test your code through
1376 **If you still find yourself needing to test internal implementation code,
1377 consider if there's a better design.** The desire to test internal
1382 If you absolutely have to test non-public interface code though, you can. There
1389 To test them, we use the following special techniques:
1392 are only visible within the same translation unit. To test them, you can
1401 internal header, but your clients are not. This way, you can fully test your
1405 friends. To access a class' private members, you can declare your test
1413 Another way to test private members is to refactor them into an
1420 Or, you can declare an individual test as a friend of your class by adding
1448 your test fixtures and tests to be friends of your class, then they must be
1466 Your test code should be something like:
1484 If you are building a testing utility on top of googletest, you'll want to test
1485 your utility. What framework would you use to test it? googletest, of course.
1490 we test that a piece of code generates an expected failure?
1554 `Fixture` is the test fixture class for the test. All tests registered with the
1606 Sometimes a function may need to know the name of the currently running test.
1607 For example, you may be using the `SetUp()` method of your test fixture to set
1608 the golden file name based on which test is running. The
1611 To obtain a `TestInfo` object for the currently running test, call
1616 // Gets information about the currently running test.
1621 printf("We are in test %s of test suite %s.\n",
1626 `current_test_info()` returns a null pointer if no test is running. In
1627 particular, you cannot find the test suite name in `SetUpTestSuite()`,
1628 `TearDownTestSuite()` (where you know the test suite name implicitly), or
1634 about the progress of a test program and test failures. The events you can
1635 listen to include the start and end of the test program, a test suite, or a test
1638 of output, such as a GUI or a database. You can also use test events as
1647 overridden to handle a test event* (For example, when a test starts, the
1655 * UnitTest reflects the state of the entire test program,
1656 * TestSuite has information about a test suite, which can contain one or more
1658 * TestInfo contains the state of a test, and
1659 * TestPartResult represents the result of a test assertion.
1662 interesting information about the event and the test program's state.
1668 // Called before a test starts.
1683 // Called after a test ends.
1711 There's only one problem: the default test result printer is still in effect, so
1712 its output will mingle with the output from your minimalist printer. To suppress
1748 ensures that failures generated by the latter are attributed to the right test
1757 googletest test programs are ordinary executables. Once built, you can run them
1762 To see a list of supported flags and their usage, please run your test program
1763 with the `--help` flag. You can also use `-h`, `-?`, or `/?` for short.
1798 '`:`'-separated pattern list (called the *negative patterns*). A test matches
1811 * `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite
1813 * `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
1816 * `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
1819 everything in test suite `FooTest` except `FooTest.Bar` and everything in
1820 test suite `BarTest` except `BarTest.Foo`.
1822 #### Stop test execution upon first failure
1825 cases (e.g. iterative test development & execution) it may be desirable stop
1826 test execution upon first failure (trading improved latency for completeness).
1828 the test runner will stop execution as soon as the first test failure is found.
1832 If you have a broken test that you cannot fix right away, you can add the
1837 If you need to disable all tests in a test suite, you can either add `DISABLED_`
1838 to the front of the name of each test, or alternatively add it to the front of
1839 the test suite name.
1857 a banner warning you if a test program contains any disabled tests.
1862 improving your test quality.
1866 To include disabled tests in test execution, just invoke the test program with
1869 You can combine this with the `--gtest_filter` flag to further select which
1874 Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it
1878 The `--gtest_repeat` flag allows you to repeat all (or selected) test methods in
1879 a program many times. Hopefully, a flaky test will eventually fail and give you
1891 is especially useful when running under a debugger: when the test
1899 If your test program contains
1912 the random seed value, such that you can reproduce an order-related test failure
1919 If you combine this with `--gtest_repeat=N`, googletest will pick a different
1930 <font color="green">[----------]</font> 1 test from FooTest
1940 <font color="green">[==========]</font> 30 tests from 14 test suites ran.
1955 #### Suppressing test passes
1957 By default, googletest prints 1 line of output for each test, indicating if it
1958 passed or failed. To show only test failures, run the test program with
1963 By default, googletest prints the time it takes to run each test. To disable
1964 that, run the test program with the `--gtest_print_time=0` command line flag, or
1973 the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
1979 textual output. The report contains the duration of each test, and thus can help
1990 that directory, named after the test executable (e.g. `foo_test.xml` for test
2001 <testsuite name="test_case_name" ...>
2007 </testsuite>
2011 * The root `<testsuites>` element corresponds to the entire test program.
2012 * `<testsuite>` elements correspond to googletest test suites.
2013 * `<testcase>` elements correspond to googletest test functions.
2028 <testsuite name="MathTest" tests="2" failures="1" errors="0" time="0.015">
2035 </testsuite>
2036 <testsuite name="LogicTest" tests="1" failures="0" errors="0" time="0.005">
2039 </testsuite>
2045 * The `tests` attribute of a `<testsuites>` or `<testsuite>` element tells how
2046 many test functions the googletest program or test suite contains, while the
2049 * The `time` attribute expresses the duration of the test, test suite, or
2050 entire test program in seconds.
2052 * The `timestamp` attribute records the local date and time of the test
2082 "testsuite": {
2166 repeated TestInfo testsuite = 7;
2211 "testsuite": [
2242 "testsuite": [
2262 Google Test implements the _premature-exit-file_ protocol for test runners to
2263 catch any kind of unexpected exits of test programs. Upon start, Google Test
2265 finished. Then, the test runner can check if this file exists. In case the file
2266 remains undeleted, the inspected test has exited prematurely.
2273 When running test programs under a debugger, it's very convenient if the
2283 googletest can be used either with or without exceptions enabled. If a test
2285 googletest catches it, reports it as a test failure, and continues with the next
2286 test method. This maximizes the coverage of a test run. Also, on Windows an
2290 When debugging the test failures, however, you may instead want the exceptions
2322 After compiling your project with one of the sanitizers enabled, if a particular
2323 test triggers a sanitizer error, googletest will report that it failed.