Lines Matching +full:technical +full:- +full:articles
18 See [Explicit Success and Failure](reference/assertions.md#success-failure) in
35 is awkward especially when the expression has side-effects or is expensive to
135 #### Using a Predicate-Formatter
141 instead use *predicate-formatter assertions* to *fully* customize how the
146 ### Floating-Point Comparison
148 See [Floating-Point Comparison](reference/assertions.md#floating-point) in the
151 #### Floating-Point Predicate-Format Functions
153 Some floating-point operations are useful, but not that often used. In order to
154 avoid an explosion of new macros, we provide them as predicate-format functions
177 (Please read the [previous](#asserting-using-gmock-matchers) section first if
180 You can use the gMock [string matchers](reference/matchers.md#string-matchers)
182 comparison tricks (sub-string, prefix, suffix, regular expression, and etc). For
243 void-returning functions. This is a consequence of Google's not using
244 exceptions. By placing it in a non-void function you'll get a confusing compile
249 If you need to use fatal assertions in a function that returns non-void, one
257 that generate non-fatal failures, such as `ADD_FAILURE*` and `EXPECT_*`.
260 NOTE: Constructors and destructors are not considered void-returning functions,
268 WARNING: A fatal assertion in a helper function (private void-returning method)
271 destructor early, possibly leaving your object in a partially-constructed or
272 partially-destructed state! You almost certainly want to `abort` or use
310 values to help you debug. It does this using a user-extensible value printer.
312 This printer knows how to print built-in C++ types, native arrays, STL
338 // C++'s look-up rules rely on that.
354 `AbslStringify()` can also use `absl::StrFormat`'s catch-all `%v` type specifier
378 // is defined in the SAME namespace that defines Point. C++'s look-up rules
428 ["Catching" Failures](#catching-failures).
473 is the exit status non-zero? And
486 [Death Tests And Threads](#death-tests-and-threads) section below explains why.
523 ---------- | --------------------------------------------------------------
559 well-known problems with forking in the presence of threads, death tests should
560 be run in a single-threaded context. Sometimes, however, it isn't feasible to
561 arrange that kind of environment. For example, statically-initialized modules
622 Since `statement` runs in the child process, any in-memory side effect (e.g.
640 ## Using Assertions in Sub-routines
651 If a test sub-routine is called from several places, when an assertion inside it
652 fails, it can be hard to tell which invocation of the sub-routine the failure is
714 beginning of a sub-routine, instead of at each call site.
715 2. When calling sub-routines inside a loop, make the loop iterator part of the
719 particular invocation of a sub-routine. In this case, you don't have to
724 5. The trace dump is clickable in Emacs - hit `return` on a line number and
759 The following code can turn ASSERT-failure into an exception:
771 testing::UnitTest::GetInstance()->listeners().Append(new ThrowListener);
789 ------------------------------------- | ------------------------------------- | --------
813 functions to catch fatal failures in a sub-routine and return early.
845 least one non-fatal failure, and `HasFailure()` returns `true` if the current
853 [XML output](#generating-an-xml-report) if you specify one. For example, the
885 > the top-level XML element.
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:
925 Here's an example of per-test-suite set-up and tear-down:
930 // Per-test-suite set-up.
945 // Per-test-suite tear-down.
953 // You can define per-test set-up logic as usual.
956 // You can define per-test tear-down logic as usual.
979 ## Global Set-Up and Tear-Down
981 Just as you can do set-up and tear-down at the test level and the test suite
985 environment, which knows how to set-up and tear-down:
1047 ## Value-Parameterized Tests
1049 *Value-parameterized tests* allow you to test your code with different
1054 command-line flags. You want to make sure your code performs correctly for
1057 * You want to test your code over various inputs (a.k.a. data-driven testing).
1061 ### How to Write Value-Parameterized Tests
1063 To write value-parameterized tests, first you should define a fixture class. It
1085 // Or, when you want to add parameters to a pre-existing fixture class:
1120 [`Values`](reference/testing.md#param-generators) parameter generator:
1135 [parameter generator](reference/testing.md#param-generators).
1154 You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests).
1158 [`ValuesIn`](reference/testing.md#param-generators) parameter generator:
1192 ### Creating Value-Parameterized Abstract Tests
1195 Sometimes you may want to define value-parameterized tests in a library and let
1201 get all the interface-conformance tests for free.
1216 ### Specifying Names for Value-Parameterized Test Parameters
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-underscore)
1322 TypeParam n = this->value_;
1343 ## Type-Parameterized Tests
1345 *Type-parameterized tests* are like typed tests, except that they don't require
1351 type-parameterized tests to verify properties that any valid implementation of
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
1382 this->DoSomethingInteresting()
1426 black-box testing principle, most of the time you should test your code through
1435 If you absolutely have to test non-public interface code though, you can. There
1447 (#including `.cc` files is not a good way to reuse code - you should not do
1452 normally uses, and put the private declarations in a `*-internal.h` file.
1463 friends to it, as they are technically defined in sub-classes of the
1467 implementation class, which is then declared in a `*-internal.h` file. Your
1470 [Pimpl](https://www.gamedev.net/articles/programming/general-and-gameplay-programming/the-c-pimpl-r1794/)
1545 `"gtest/gtest-spi.h"` contains some constructs to do this.
1559 if you are expecting a non-fatal (e.g. `EXPECT_*`) failure.
1574 For technical reasons, there are some caveats:
1579 local non-static variables or non-static members of `this` object.
1604 The `factory` argument is a factory callable (move-constructible) object or
1645 [=]() -> MyFixture* { return new MyTest(v); });
1671 // Do NOT delete the returned object - it's managed by the UnitTest class.
1673 testing::UnitTest::GetInstance()->current_test_info();
1676 test_info->name(),
1677 test_info->test_suite_name());
1749 [`TestEventListeners`](reference/testing.md#TestEventListeners) - note the "s"
1758 testing::UnitTest::GetInstance()->listeners();
1792 You may use failure-raising macros (`EXPECT_*()`, `ASSERT_*()`, `FAIL()`, etc)
1805 See [sample10_unittest.cc] for an example of a failure-raising listener.
1807 [sample10_unittest.cc]: https://github.com/google/googletest/blob/main/googletest/samples/sample10_unittest.cc "Failure-raising listener example"
1817 with the `--help` flag.
1828 `--gtest_list_tests` overrides all other flags and lists tests in the following
1847 `--gtest_filter` flag to a filter string, GoogleTest will only run the tests
1850 The format of a filter is a '`:`'-separated list of wildcard patterns (called
1851 the *positive patterns*) optionally followed by a '`-`' and another
1852 '`:`'-separated pattern list (called the *negative patterns*). A test matches
1857 character). For convenience, the filter `'*-NegativePatterns'` can be also
1858 written as `'-NegativePatterns'`.
1863 * `./foo_test --gtest_filter=*` Also runs everything, due to the single
1864 match-everything `*` value.
1865 * `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite
1867 * `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
1869 * `./foo_test --gtest_filter=-*DeathTest.*` Runs all non-death tests.
1870 * `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
1872 * `./foo_test --gtest_filter=FooTest.*:BarTest.*-FooTest.Bar:BarTest.Foo` Runs
1881 If `GTEST_FAIL_FAST` environment variable or `--gtest_fail_fast` flag is set,
1909 NOTE: This feature should only be used for temporary pain-relief. You still have
1921 the `--gtest_also_run_disabled_tests` flag or set the
1923 You can combine this with the `--gtest_filter` flag to further select which
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
1937 $ foo_test --gtest_repeat=1000
1940 $ foo_test --gtest_repeat=-1
1943 $ foo_test --gtest_repeat=1000 --gtest_break_on_failure
1949 $ foo_test --gtest_repeat=1000 --gtest_filter=FooBar.*
1954 [global set-up/tear-down](#global-set-up-and-tear-down) code, it will be
1956 repeating global set-up/tear-down, specify
1957 `--gtest_recreate_environments_when_repeating=false`{.nowrap}.
1964 You can specify the `--gtest_shuffle` flag (or set the `GTEST_SHUFFLE`
1970 the random seed value, such that you can reproduce an order-related test failure
1971 later. To specify the random seed explicitly, use the `--gtest_random_seed=SEED`
1977 If you combine this with `--gtest_repeat=N`, GoogleTest will pick a different
1978 random seed and re-shuffle the tests in each iteration.
1994 must be in the range `[0, GTEST_TOTAL_SHARDS - 1]`.
2004 to a non-existent file path. If a test program supports sharding, it will create
2040 <font color="green">[----------]</font> 1 test from FooTest
2043 <font color="green">[----------]</font> 2 tests from BarTest
2059 You can set the `GTEST_COLOR` environment variable or the `--gtest_color`
2062 will use colors if and only if the output goes to a terminal and (on non-Windows
2063 platforms) the `TERM` environment variable is set to `xterm` or `xterm-color`.
2069 `--gtest_brief=1`, or set the GTEST_BRIEF environment variable to `1`.
2074 that, run the test program with the `--gtest_print_time=0` command line flag, or
2077 #### Suppressing UTF-8 Text Output
2080 type `string` both as hex-encoded strings as well as in readable UTF-8 text if
2081 they contain valid non-ASCII UTF-8 characters. If you want to suppress the UTF-8
2082 text because, for example, you don't have an UTF-8 compatible output medium, run
2083 the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
2093 `--gtest_output` flag to the string `"xml:path_to_output_file"`, which will
2136 <?xml version="1.0" encoding="UTF-8"?>
2137 <testsuites tests="3" failures="1" errors="0" time="0.035" timestamp="2011-10-31T18:52:42" name="AllTests">
2141 <failure message="Value of: add(1, -1)
 Actual: 1
Expected: 0" type="">...</failure>
2175 `--gtest_output` flag to the string `"json:path_to_output_file"`, which will
2184 "$schema": "https://json-schema.org/schema#",
2238 "format": "date-time"
2253 [JSON encoding](https://developers.google.com/protocol-buffers/docs/proto3#json):
2319 "timestamp": "2011-10-31T18:52:42Z",
2342 "message": "Value of: add(1, -1)\n Actual: 1\nExpected: 0",
2385 Google Test implements the _premature-exit-file_ protocol for test runners to
2394 #### Turning Assertion Failures into Break-Points
2398 mode. GoogleTest's *break-on-failure* mode supports this behavior.
2401 other than `0`. Alternatively, you can use the `--gtest_break_on_failure`
2404 #### Disabling Catching Test-Thrown Exceptions
2410 uncaught exception will cause a pop-up window, so catching the exceptions allows
2416 environment variable to `0`, or use the `--gtest_catch_exceptions=0` flag when