Lines Matching +refs:test +refs:catch
8 messages, propagate fatal failures, reuse and speed up your test fixtures, and
241 a method of the test fixture class. The one constraint is that assertions that
263 call `abort` and crash the entire test executable, or put the fatal assertion in
269 called from a constructor or destructor does not terminate the current test, as
275 ## Skipping test execution
277 Related to the assertions `SUCCEED()` and `FAIL()`, you can prevent further test
279 to check for preconditions of the system under test during runtime and skip
282 `GTEST_SKIP()` can be used in individual test cases or in the `SetUp()` methods
288 GTEST_SKIP() << "Skipping single test";
309 When a test assertion such as `EXPECT_EQ` fails, GoogleTest prints the argument
354 `AbslStringify()` can also use `absl::StrFormat`'s catch-all `%v` type specifier
415 corruption, security holes, or worse. Hence it is vitally important to test that
419 _death tests_. More generally, any test that checks that a program terminates
420 (except by throwing an exception) in an expected fashion is also a death test.
423 for the purpose of death tests, as the caller of the code could catch the
427 If you want to test `EXPECT_*()/ASSERT_*()` failures in your test code, see
436 To write a death test, simply use one of the macros inside your test function.
441 // This death test uses a compound statement.
465 The test function body may contain other assertions and statements as well, if
468 Note that a death test only cares about three things:
477 will **not** cause the death test to fail, as GoogleTest assertions don't abort
484 **test suite** (not test) `*DeathTest` when it contains a death test, as
488 If a test fixture class is shared by normal tests and death tests, you can use
498 // normal test
502 // death test
558 The reason for the two death test styles has to do with thread safety. Due to
567 1. A warning is emitted if multiple threads are running when a death test is
575 It's perfectly fine to create threads inside a death test statement; they are
580 The "threadsafe" death test style was introduced in order to help mitigate the
582 test execution time (potentially dramatically so) for improved thread safety.
592 or in individual tests. Recall that flags are saved before running each test and
604 // This test is run in the "threadsafe" style:
609 // This test is run in the "fast" style:
618 exception, the death test is considered to have failed. Some GoogleTest macros
624 in the parent process. In particular, if you release memory in a death test,
628 1. try not to free memory in a death test;
632 Due to an implementation detail, you cannot place multiple death test assertions
637 test, thread problems such as deadlock are still possible in the presence of
643 Note: If you want to put a series of test assertions in a subroutine to check
651 If a test sub-routine is called from several places, when an assertion inside it
668 line number in arguments, which is useful for writing test helpers. The effect
730 when they fail they only abort the _current function_, not the entire test. For
731 example, the following test will segfault:
744 // in Subroutine() to abort the entire test.
781 As shown above, if your test calls a subroutine that has an `ASSERT_*` failure
782 in it, the test will continue after the subroutine returns. This may not be what
812 assertion in the current test has suffered a fatal failure. This allows
813 functions to catch fatal failures in a sub-routine and return early.
837 If `HasFatalFailure()` is used outside of `TEST()` , `TEST_F()` , or a test
844 Similarly, `HasNonfatalFailure()` returns `true` if the current test has at
846 test has at least one failure of either kind.
850 In your test code, you can call `RecordProperty("key", value)` to log additional
854 test
867 …<testcase name="MinAndMaxWidgets" file="test.cpp" line="1" status="run" time="0.006" classname="Wi…
876 > `TEST` body and the test fixture class.
880 > * Calling `RecordProperty()` outside of the lifespan of a test is allowed.
881 > If it's called outside of a test but between a test suite's
883 > attributed to the XML element for the test suite. If it's called outside
884 > of all test suites (e.g. in a test environment), it will be attributed to
889 GoogleTest creates a new test fixture object for each test in order to make
891 that are expensive to set up, making the one-copy-per-test model prohibitively
895 single resource copy. So, in addition to per-test set-up/tear-down, GoogleTest
896 also supports per-test-suite set-up/tear-down. To use it:
898 1. In your test fixture class (say `FooTest` ), declare as `static` some member
900 2. Outside your test fixture class (typically just below it), define those
902 3. In the same test fixture class, define a public member function `static void
908 *first test* in the `FooTest` test suite (i.e. before creating the first
909 `FooTest` object), and calls `TearDownTestSuite()` after running the *last test*
913 Remember that the test order is undefined, so your code can't depend on a test
916 state to its original value before passing control to the next test.
918 Note that `SetUpTestSuite()` may be called multiple times for a test fixture
925 Here's an example of per-test-suite set-up and tear-down:
930 // Per-test-suite set-up.
931 // Called before the first test in this test suite.
945 // Per-test-suite tear-down.
946 // Called after the last test in this test suite.
953 // You can define per-test set-up logic as usual.
956 // You can define per-test tear-down logic as usual.
981 Just as you can do set-up and tear-down at the test level and the test suite
982 level, you can also do it at the test program level. Here's how.
984 First, you subclass the `::testing::Environment` class to define a test
1013 test to be performed. Importantly, `TearDown()` is executed even if the test is
1019 iteration. However, if test environments are not recreated for each iteration,
1049 *Value-parameterized tests* allow you to test your code with different
1050 parameters without writing multiple copies of the same test. This is useful in a
1056 * You want to test different implementations of an OO interface.
1057 * You want to test your code over various inputs (a.k.a. data-driven testing).
1073 NOTE: If your test fixture defines `SetUpTestSuite()` or `TearDownTestSuite()`
1081 // To access the test parameter, call GetParam() from class
1095 Then, use the `TEST_P` macro to define as many test patterns using this fixture
1101 // Inside a test, access the test parameter with the GetParam() method
1113 test suite with any set of parameters you want. GoogleTest defines a number of
1114 functions for generating test parameters—see details at
1119 test suite each with parameter values `"meeny"`, `"miny"`, and `"moe"` using the
1133 instantiation of the test suite. The next argument is the name of the test
1142 You can instantiate a test pattern more than once, so to distinguish different
1144 actual test suite name. Remember to pick unique prefixes for different
1173 given test suite, whether their definitions come before or *after* the
1177 `INSTANTIATE_TEST_SUITE_P` causes a failing test in test suite
1178 `GoogleTestVerification`. If you have a test suite where that omission is not an
1180 where the list of test cases is dynamic and may be empty, then this check can be
1181 suppressed by tagging the test suite:
1199 the test parameter) that all implementations of the interface are expected to
1205 1. Put the definition of the parameterized test fixture class (e.g. `FooTest`)
1213 contains `foo_param_test.cc`. You can instantiate the same abstract test suite
1219 specify a function or functor that generates custom test name suffixes based on
1220 the test parameters. The function should accept one argument of type
1223 `testing::PrintToStringParamName` is a builtin test suffix generator that
1228 NOTE: test names must be non-empty, unique, and may only contain ASCII
1230 [should not contain underscores](faq.md#why-should-test-suite-names-and-test-names-not-contain-unde…
1244 Providing a custom functor allows for more control over test parameter name
1276 verify it. In both cases, you want the same test logic repeated for different
1279 While you can write one `TEST` or `TEST_F` for each type you want to test (and
1280 you may even factor the test logic into a function template that you invoke from
1284 *Typed tests* allow you to repeat the same test logic over a list of types. You
1285 only need to write the test logic once, although you must know the type list
1302 Next, associate a list of types with the test suite, which will be repeated for
1314 Then, use `TYPED_TEST()` instead of `TEST_F()` to define a typed test for this
1315 test suite. You can repeat this as many times as you want:
1319 // Inside a test, refer to the special name TypeParam to get the type
1346 you to know the list of types ahead of time. Instead, you can define the test
1353 just instantiate the test suite with their type to verify that it conforms to
1367 Next, declare that you will define a type-parameterized test suite:
1373 Then, use `TYPED_TEST_P()` to define a type-parameterized test. You can repeat
1378 // Inside a test, refer to TypeParam to get the type parameter.
1389 Now the tricky part: you need to register all test patterns using the
1391 argument of the macro is the test suite name; the rest are the names of the
1392 tests in this test suite:
1410 actual test suite name. Remember to pick unique prefixes for different
1426 black-box testing principle, most of the time you should test your code through
1429 **If you still find yourself needing to test internal implementation code,
1430 consider if there's a better design.** The desire to test internal
1435 If you absolutely have to test non-public interface code though, you can. There
1442 To test them, we use the following special techniques:
1445 are only visible within the same translation unit. To test them, you can
1454 internal header, but your clients are not. This way, you can fully test your
1458 friends. To access a class' private members, you can declare your test
1466 Another way to test private members is to refactor them into an
1473 Or, you can declare an individual test as a friend of your class by adding
1501 your test fixtures and tests to be friends of your class, then they must be
1519 Your test code should be something like:
1537 If you are building a testing utility on top of GoogleTest, you'll want to test
1538 your utility. What framework would you use to test it? GoogleTest, of course.
1541 In frameworks that report a failure by throwing an exception, you could catch
1543 we test that a piece of code generates an expected failure?
1563 threads are also ignored. If you want to catch failures in other threads as
1607 `Fixture` is the test fixture class for the test. All tests registered with the
1660 Sometimes a function may need to know the name of the currently running test.
1661 For example, you may be using the `SetUp()` method of your test fixture to set
1662 the golden file name based on which test is running. The
1665 To obtain a `TestInfo` object for the currently running test, call
1670 // Gets information about the currently running test.
1675 printf("We are in test %s of test suite %s.\n",
1680 `current_test_info()` returns a null pointer if no test is running. In
1681 particular, you cannot find the test suite name in `SetUpTestSuite()`,
1682 `TearDownTestSuite()` (where you know the test suite name implicitly), or
1688 about the progress of a test program and test failures. The events you can
1689 listen to include the start and end of the test program, a test suite, or a test
1692 of output, such as a GUI or a database. You can also use test events as
1701 overridden to handle a test event* (For example, when a test starts, the
1709 * UnitTest reflects the state of the entire test program,
1710 * TestSuite has information about a test suite, which can contain one or more
1712 * TestInfo contains the state of a test, and
1713 * TestPartResult represents the result of a test assertion.
1716 interesting information about the event and the test program's state.
1722 // Called before a test starts.
1737 // Called after a test ends.
1765 There's only one problem: the default test result printer is still in effect, so
1802 ensures that failures generated by the latter are attributed to the right test
1811 GoogleTest test programs are ordinary executables. Once built, you can run them
1816 To see a list of supported flags and their usage, please run your test program
1852 '`:`'-separated pattern list (called the *negative patterns*). A test matches
1865 * `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite
1867 * `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
1870 * `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
1873 everything in test suite `FooTest` except `FooTest.Bar` and everything in
1874 test suite `BarTest` except `BarTest.Foo`.
1876 #### Stop test execution upon first failure
1879 cases (e.g. iterative test development & execution) it may be desirable stop
1880 test execution upon first failure (trading improved latency for completeness).
1882 the test runner will stop execution as soon as the first test failure is found.
1886 If you have a broken test that you cannot fix right away, you can add the
1891 If you need to disable all tests in a test suite, you can either add `DISABLED_`
1892 to the front of the name of each test, or alternatively add it to the front of
1893 the test suite name.
1911 a banner warning you if a test program contains any disabled tests.
1916 improving your test quality.
1920 To include disabled tests in test execution, just invoke the test program with
1928 Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it
1932 The `--gtest_repeat` flag allows you to repeat all (or selected) test methods in
1933 a program many times. Hopefully, a flaky test will eventually fail and give you
1945 is especially useful when running under a debugger: when the test
1953 If your test program contains
1970 the random seed value, such that you can reproduce an order-related test failure
1982 If you have more than one machine you can use to run a test program, you might
1983 want to run the test functions in parallel and get the result faster. We call
1986 GoogleTest is compatible with test sharding. To take advantage of this feature,
1987 your test runner (not part of GoogleTest) needs to do the following:
1995 1. Run the same test program on all shards. When GoogleTest sees the above two
1996 environment variables, it will select a subset of the test functions to run.
1997 Across all shards, each test function in the program will be run exactly
2002 understand this protocol. In order for your test runner to figure out which test
2004 to a non-existent file path. If a test program supports sharding, it will create
2009 Here's an example to make it clear. Suppose you have a test program `foo_test`
2010 that contains the following 5 test functions:
2020 Suppose you have 3 machines at your disposal. To run the test functions in
2040 <font color="green">[----------]</font> 1 test from FooTest
2050 <font color="green">[==========]</font> 30 tests from 14 test suites ran.
2065 #### Suppressing test passes
2067 By default, GoogleTest prints 1 line of output for each test, indicating if it
2068 passed or failed. To show only test failures, run the test program with
2073 By default, GoogleTest prints the time it takes to run each test. To disable
2074 that, run the test program with the `--gtest_print_time=0` command line flag, or
2083 the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
2089 textual output. The report contains the duration of each test, and thus can help
2100 that directory, named after the test executable (e.g. `foo_test.xml` for test
2121 * The root `<testsuites>` element corresponds to the entire test program.
2122 * `<testsuite>` elements correspond to GoogleTest test suites.
2123 * `<testcase>` elements correspond to GoogleTest test functions.
2139 <testcase name="Addition" file="test.cpp" line="1" status="run" time="0.007" classname="">
2143 <testcase name="Subtraction" file="test.cpp" line="2" status="run" time="0.005" classname="">
2147 … <testcase name="NonContradiction" file="test.cpp" line="3" status="run" time="0.005" classname="">
2156 many test functions the GoogleTest program or test suite contains, while the
2159 * The `time` attribute expresses the duration of the test, test suite, or
2160 entire test program in seconds.
2162 * The `timestamp` attribute records the local date and time of the test
2166 test was defined.
2331 "file": "test.cpp",
2349 "file": "test.cpp",
2366 "file": "test.cpp",
2385 Google Test implements the _premature-exit-file_ protocol for test runners to
2386 catch any kind of unexpected exits of test programs. Upon start, Google Test
2388 finished. Then, the test runner can check if this file exists. In case the file
2389 remains undeleted, the inspected test has exited prematurely.
2396 When running test programs under a debugger, it's very convenient if the
2397 debugger can catch an assertion failure and automatically drop into interactive
2406 GoogleTest can be used either with or without exceptions enabled. If a test
2408 GoogleTest catches it, reports it as a test failure, and continues with the next
2409 test method. This maximizes the coverage of a test run. Also, on Windows an
2413 When debugging the test failures, however, you may instead want the exceptions
2446 test triggers a sanitizer error, GoogleTest will report that it failed.