Lines Matching +full:json +full:- +full:parse +full:- +full:even +full:- +full:better +full:- +full:errors
18 See [Explicit Success and Failure](reference/assertions.md#success-failure) in
26 ### Predicate Assertions for Better Error Messages
28 Even though GoogleTest has a rich set of assertions, they can never be complete,
31 complex expression, for lack of a better macro. This has the problem of not
35 is awkward especially when the expression has side-effects or is expensive to
121 return testing::AssertionSuccess() << n << " is even";
131 Actual: true (8 is even)
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
252 need to make sure that `*result` contains some sensible value even when the
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
317 to do a better job at printing your particular type than to dump the bytes. To
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
654 messages, but that usually clutters up your tests. A better solution is to use
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:
1037 ## Value-Parameterized Tests
1039 *Value-parameterized tests* allow you to test your code with different
1044 command-line flags. You want to make sure your code performs correctly for
1047 * You want to test your code over various inputs (a.k.a. data-driven testing).
1051 ### How to Write Value-Parameterized Tests
1053 To write value-parameterized tests, first you should define a fixture class. It
1075 // Or, when you want to add parameters to a pre-existing fixture class:
1110 [`Values`](reference/testing.md#param-generators) parameter generator:
1125 [parameter generator](reference/testing.md#param-generators).
1144 You can use these names in [`--gtest_filter`](#running-a-subset-of-the-tests).
1148 [`ValuesIn`](reference/testing.md#param-generators) parameter generator:
1182 ### Creating Value-Parameterized Abstract Tests
1185 Sometimes you may want to define value-parameterized tests in a library and let
1191 get all the interface-conformance tests for free.
1206 ### Specifying Names for Value-Parameterized Test Parameters
1218 NOTE: test names must be non-empty, unique, and may only contain ASCII
1220 [should not contain underscores](faq.md#why-should-test-suite-names-and-test-names-not-contain-unde…
1270 you may even factor the test logic into a function template that you invoke from
1301 macro to parse correctly. Otherwise the compiler will think that each comma in
1312 TypeParam n = this->value_;
1333 ## Type-Parameterized Tests
1335 *Type-parameterized tests* are like typed tests, except that they don't require
1337 logic first and instantiate it with different type lists later. You can even
1341 type-parameterized tests to verify properties that any valid implementation of
1357 Next, declare that you will define a type-parameterized test suite:
1363 Then, use `TYPED_TEST_P()` to define a type-parameterized test. You can repeat
1372 this->DoSomethingInteresting()
1416 black-box testing principle, most of the time you should test your code through
1420 consider if there's a better design.** The desire to test internal
1425 If you absolutely have to test non-public interface code though, you can. There
1437 (#including `.cc` files is not a good way to reuse code - you should not do
1440 However, a better approach is to move the private code into the
1442 normally uses, and put the private declarations in a `*-internal.h` file.
1451 class via the accessors in the fixture. Note that even though your fixture
1453 friends to it, as they are technically defined in sub-classes of the
1457 implementation class, which is then declared in a `*-internal.h` file. Your
1460 …mpl](https://www.gamedev.net/articles/programming/general-and-gameplay-programming/the-c-pimpl-r17…
1535 `"gtest/gtest-spi.h"` contains some constructs to do this.
1549 if you are expecting a non-fatal (e.g. `EXPECT_*`) failure.
1569 local non-static variables or non-static members of `this` object.
1594 The `factory` argument is a factory callable (move-constructible) object or
1635 [=]() -> MyFixture* { return new MyTest(v); });
1661 // Do NOT delete the returned object - it's managed by the UnitTest class.
1663 testing::UnitTest::GetInstance()->current_test_info();
1666 test_info->name(),
1667 test_info->test_suite_name());
1739 [`TestEventListeners`](reference/testing.md#TestEventListeners) - note the "s"
1748 testing::UnitTest::GetInstance()->listeners();
1782 You may use failure-raising macros (`EXPECT_*()`, `ASSERT_*()`, `FAIL()`, etc)
1795 See [sample10_unittest.cc] for an example of a failure-raising listener.
1797 …google/googletest/blob/main/googletest/samples/sample10_unittest.cc "Failure-raising listener exam…
1807 with the `--help` flag. You can also use `-h`, `-?`, or `/?` for short.
1818 `--gtest_list_tests` overrides all other flags and lists tests in the following
1837 `--gtest_filter` flag to a filter string, GoogleTest will only run the tests
1840 The format of a filter is a '`:`'-separated list of wildcard patterns (called
1841 the *positive patterns*) optionally followed by a '`-`' and another
1842 '`:`'-separated pattern list (called the *negative patterns*). A test matches
1847 character). For convenience, the filter `'*-NegativePatterns'` can be also
1848 written as `'-NegativePatterns'`.
1853 * `./foo_test --gtest_filter=*` Also runs everything, due to the single
1854 match-everything `*` value.
1855 * `./foo_test --gtest_filter=FooTest.*` Runs everything in test suite
1857 * `./foo_test --gtest_filter=*Null*:*Constructor*` Runs any test whose full
1859 * `./foo_test --gtest_filter=-*DeathTest.*` Runs all non-death tests.
1860 * `./foo_test --gtest_filter=FooTest.*-FooTest.Bar` Runs everything in test
1862 * `./foo_test --gtest_filter=FooTest.*:BarTest.*-FooTest.Bar:BarTest.Foo` Runs
1871 If `GTEST_FAIL_FAST` environment variable or `--gtest_fail_fast` flag is set,
1878 better than commenting out the code or using `#if 0`, as disabled tests are
1885 For example, the following tests won't be run by GoogleTest, even though they
1899 NOTE: This feature should only be used for temporary pain-relief. You still have
1911 the `--gtest_also_run_disabled_tests` flag or set the
1913 You can combine this with the `--gtest_filter` flag to further select which
1918 Once in a while you'll run into a test whose result is hit-or-miss. Perhaps it
1922 The `--gtest_repeat` flag allows you to repeat all (or selected) test methods in
1927 $ foo_test --gtest_repeat=1000
1930 $ foo_test --gtest_repeat=-1
1933 $ foo_test --gtest_repeat=1000 --gtest_break_on_failure
1939 $ foo_test --gtest_repeat=1000 --gtest_filter=FooBar.*
1944 [global set-up/tear-down](#global-set-up-and-tear-down) code, it will be
1946 repeating global set-up/tear-down, specify
1947 `--gtest_recreate_environments_when_repeating=false`{.nowrap}.
1954 You can specify the `--gtest_shuffle` flag (or set the `GTEST_SHUFFLE`
1960 the random seed value, such that you can reproduce an order-related test failure
1961 later. To specify the random seed explicitly, use the `--gtest_random_seed=SEED`
1967 If you combine this with `--gtest_repeat=N`, GoogleTest will pick a different
1968 random seed and re-shuffle the tests in each iteration.
1984 must be in the range `[0, GTEST_TOTAL_SHARDS - 1]`.
1994 to a non-existent file path. If a test program supports sharding, it will create
2030 <font color="green">[----------]</font> 1 test from FooTest
2033 <font color="green">[----------]</font> 2 tests from BarTest
2049 You can set the `GTEST_COLOR` environment variable or the `--gtest_color`
2052 will use colors if and only if the output goes to a terminal and (on non-Windows
2053 platforms) the `TERM` environment variable is set to `xterm` or `xterm-color`.
2059 `--gtest_brief=1`, or set the GTEST_BRIEF environment variable to `1`.
2064 that, run the test program with the `--gtest_print_time=0` command line flag, or
2067 #### Suppressing UTF-8 Text Output
2070 type `string` both as hex-encoded strings as well as in readable UTF-8 text if
2071 they contain valid non-ASCII UTF-8 characters. If you want to suppress the UTF-8
2072 text because, for example, you don't have an UTF-8 compatible output medium, run
2073 the test program with `--gtest_print_utf8=0` or set the `GTEST_PRINT_UTF8`
2083 `--gtest_output` flag to the string `"xml:path_to_output_file"`, which will
2126 <?xml version="1.0" encoding="UTF-8"?>
2127 <testsuites tests="3" failures="1" errors="0" time="0.035" timestamp="2011-10-31T18:52:42" name="Al…
2128 <testsuite name="MathTest" tests="2" failures="1" errors="0" time="0.015">
2131 … <failure message="Value of: add(1, -1)
 Actual: 1
Expected: 0" type="">...</failure>
2136 <testsuite name="LogicTest" tests="1" failures="0" errors="0" time="0.005">
2161 #### Generating a JSON Report
2163 GoogleTest can also emit a JSON report as an alternative format to XML. To
2164 generate the JSON report, set the `GTEST_OUTPUT` environment variable or the
2165 `--gtest_output` flag to the string `"json:path_to_output_file"`, which will
2167 `"json"`, in which case the output can be found in the `test_detail.json` file
2170 The report format conforms to the following JSON Schema:
2172 ```json
2174 "$schema": "https://json-schema.org/schema#",
2225 "errors": { "type": "integer" },
2228 "format": "date-time"
2243 [JSON encoding](https://developers.google.com/protocol-buffers/docs/proto3#json):
2257 int32 errors = 4;
2269 int32 errors = 5;
2303 ```json
2307 "errors": 0,
2309 "timestamp": "2011-10-31T18:52:42Z",
2316 "errors": 0,
2332 "message": "Value of: add(1, -1)\n Actual: 1\nExpected: 0",
2351 "errors": 0,
2369 IMPORTANT: The exact format of the JSON document is subject to change.
2375 Google Test implements the _premature-exit-file_ protocol for test runners to
2384 #### Turning Assertion Failures into Break-Points
2388 mode. GoogleTest's *break-on-failure* mode supports this behavior.
2391 other than `0`. Alternatively, you can use the `--gtest_break_on_failure`
2394 #### Disabling Catching Test-Thrown Exceptions
2400 uncaught exception will cause a pop-up window, so catching the exceptions allows
2406 environment variable to `0`, or use the `--gtest_catch_exceptions=0` flag when
2417 when they detect sanitizer errors, such as creating a reference from `nullptr`.