NOTE: if you suspect that this change breaks your build, it's likely that your tests depend on the exact messages of `ElementsAre()` and friends. The messages are implementation details of these matcher and are subject to change without notice. Depending on the messages is not supported. In that case, please rewrite your tests to avoid the dependency.
When the array being matched is long, it can be hard for the user to find the mismatched element in the message generated by `ElementsAre()` or `ElementsAreArray()` - even though these matchers print the index of the mismatched element, the user still has to count to find the actual element and its corresponding matcher.
With this change, these matchers will include the actual value and corresponding matcher in the failure message, making it easier for the user.
Also make a small style improvement: now it's advised to write
```
EXPECT_EQ(actual, expected);
```
as opposed to
```
EXPECT_EQ(expected, actual);
```
PiperOrigin-RevId: 738039133
Change-Id: I3b94f7d01a6a4c92e2daf268df8cfb04a21d4294
Many gtest users aren't aware that a polymorphic matcher is not actually a `testing::Matcher<>` and thus doesn't know how to describe itself. Clarify this.
Also adds a recipe on how to define a composite matcher. In particular, explain how the composite matcher can describe itself in terms of the description(s) of its sub-matcher(s).
PiperOrigin-RevId: 735840759
Change-Id: I26cff6179349aa739fc7fdd528a2f5308d18c189
`std::abs()` doesn't work on custom types. While one can use the 3-argument version of `DistanceFrom()` to specify how to compute the distance, it's not as convenient as defining `abs()` for the custom type once in the type's namespace and then use the 2-argument version.
PiperOrigin-RevId: 735741409
Change-Id: If8fb668455eb963a2ccf089f7467c64965a2e7a6
We have a bunch of matchers for asserting that a value is near the target value, e.g.
`DoubleNear()` and `FloatNear()`. These matchers only work for specific types (`double` and `float`). They are not flexible enough to support other types that have the notion of a "distance" (e.g. N-dimensional points and vectors, which are commonly used in ML).
In this diff, we generalize the idea to a `DistanceFrom(target, get_distance, m)` matcher that works on arbitrary types that have the "distance" concept (the `get_distance` argument is optional and can be omitted for types that support `-`, and `std::abs()`). What it does:
1. compute the distance between the value and the target using `get_distance(value, target)`; if `get_distance` is omitted, compute the distance as `std::abs(value - target)`.
2. match the distance against matcher `m`; if the match succeeds, the `DistanceFrom()` match succeeds.
Examples:
```
// 0.5's distance from 0.6 should be <= 0.2.
EXPECT_THAT(0.5, DistanceFrom(0.6, Le(0.2)));
Vector2D v1(3.0, 4.0), v2(3.2, 6.0);
// v1's distance from v2, as computed by EuclideanDistance(v1, v2),
// should be >= 1.0.
EXPECT_THAT(v1, DistanceFrom(v2, EuclideanDistance, Ge(1.0)));
```
PiperOrigin-RevId: 734593292
Change-Id: Id6bb7074dc4aa4d8abd78b57ad2426637e590de5
While a testonly library can certainly depend on a non-testonly library, gtest
itself is logically testonly, but is not tagged as such for historical
reasons. Having a testonly target allows gradual migrations towards a
testonly-only world.
PiperOrigin-RevId: 731807655
Change-Id: Ie16f17fb74b80bb6200767a3ac5bafa424162146
Bazel sets the environment variable TEST_WARNINGS_OUTPUT_FILE
https://bazel.build/reference/test-encyclopedia#initial-conditions
If no tests are linked and the new flag --gtest_fail_if_no_test_linked
is not true (which is the current default), we can still warn the user
as this may be a programming error without failing the test (which would
break existing users).
PiperOrigin-RevId: 731402363
Change-Id: Ia481689efd4bd18889feaaa38bc56049a3f651cd
to fail the test program if no test case is linked in
(a common programmer mistake).
PiperOrigin-RevId: 730571311
Change-Id: I1dab04adfe35581274d0b4ec79a017014d50e1ea
* Use `[[nodiscard]]` instead of GTEST_MUST_USE_RESULT_
* Use `[[maybe_unused]]` instead of GTEST_INTERNAL_ATTRIBUTE_MAYBE_UNUSED
* Use `[[deprecated]]` instead of `GTEST_INTERNAL_DEPRECATED`
* Remove `GTEST_INTERNAL_NEED_REDUNDANT_CONSTEXPR_DECL`
PiperOrigin-RevId: 729523519
Change-Id: Ia1b901cf9c0a0e148eec419ada0e0b56aba2dd3d
Property() should not be used against member functions that you do not own. Make
this warning more prominent in matchers.md and add it to gmock-matchers.h.
PiperOrigin-RevId: 727753777
Change-Id: Idf9155103b04b98efc957ff0d0cf3a8d8662eb72
Regexps seem to have nothing in common with death tests, yet their description is planted right in the middle of the death test section.
This CL pulls the regexp section one level up and just before death tests.
PiperOrigin-RevId: 721817710
Change-Id: Idc52f450fb10960a590ceb1a70339f86d4478fe4
The original URL started with https://www.opengroup.org and fails to redirect to the reference page. According to Chrome's dev tools (Network tab), the response to that request is a HTTP 302 Found, with the new location being "balancer://pubs/onlinepubs/009695399/basedefs/xbd_chap09.html". Chrome does not know what to do with that and displays a blank page.
Changing the `www` subdomain to `pubs` results in HTTP 200.
PiperOrigin-RevId: 721804738
Change-Id: I816d08d5baf957c63ac97506d04c7cc49c3a5ce7
With this change, arbitrary property names in the testsuite no longer
cause the produced XML output to be ill-formed.
PiperOrigin-RevId: 721549090
Change-Id: Iedffa89bf914478f563c8f3b82cd50557762a665
If you have a death test that uses mock objects, it's very likely that those mock objects are not properly cleaned up before death. The gMock atexit leak detector will call `_exit(1)`, overriding your expected exit code.
PiperOrigin-RevId: 713722657
Change-Id: I92a326f3923efc9f0e235d825616f3094eca995c
This surfaces useful information about the environment failure in a structured form.
As we can see from the updated test, previously unsurfaced information is now present.
PiperOrigin-RevId: 709892315
Change-Id: I2656294d50c33f995bef5c96195a66cff3c4b907
This allows users to override the fake SDK with a real one using https://bazel.build/rules/lib/globals/module#override_repo.
Without this change, it is impossible for a project that depends on googletest as a `bazel_dep` to build tests using the "real" Fuchsia SDK, because any references to `@fuchsia_sdk` within googletest `BUILD.bazel` files unconditionally resolve to the "fake" Fuchsia SDK. With this change, if you have the real Fuchsia SDK declared in your `MODULE.bazel`, you can add the following lines to coerce googletest to use the real Fuchsia SDK as well:
fake_fuchsia_sdk_extension =
use_extension("@com_google_googletest//:fake_fuchsia_sdk.bzl", "fuchsia_sdk")
override_repo(fake_fuchsia_sdk_extension, "fuchsia_sdk")
PiperOrigin-RevId: 709139784
Change-Id: I4d10d441c76b7a2481f15723a24f11525dba3878
Adds feature test macro for C++20 <compare> header, a pretty-printer, and tests.
Inexplicably, these types aren't enums, so can't be handled with a switch.
PiperOrigin-RevId: 704783038
Change-Id: I29688989d18f43520fe610c12a447a20d2f98c95
std::vector<const T> for trivially relocatable types is not allowed by C++ and is rejected by libc++ starting from 4e112e5c1c
PiperOrigin-RevId: 686487841
Change-Id: I3c90c7c0a6e8e23ffa5ebd1702a3f30ebc4a702f
Some examples of asserts that now pass:
```
ASSERT_NEAR(inf, inf, 0)
ASSERT_NEAR(-inf, inf, inf)
ASSERT_NEAR(inf, x, inf) // x is any finite floating point value
```
PiperOrigin-RevId: 685748133
Change-Id: I7b3af377773e8e0031e4c6b86830cbbf76bf20c6
Currently it will refuse to become a `OnceAction` if its component sub-actions
have an `Action` conversion operator but don't know about `OnceAction` in
particular because although `Action` is convertible to `OnceAction`, the
compiler won't follow the chain of conversions.
Instead, teach it explicitly that it can always be a `OnceAction` when it can be
an `Action`.
PiperOrigin-RevId: 655393035
Change-Id: Ib205b518ceef5f256627f4b02cd93ec9bd98343b
and the Bazel Central Registry
GoogleTest and its dependencies now use the following names:
GoogleTest: com_google_googletest -> googletest
Abseil: com_google_absl -> abseil-cpp
RE2: com_googlesource_code_re2 -> re2
Bazel users using the WORKSPACE file to specify dependencies may
need to use https://bazel.build/rules/lib/repo/http#http_archive-repo_mapping
to remap repositories to their former names if their dependencies do not
agree on on which name is used.
It is recommended that users migrate to bzlmod to manage Bazel dependencies.
PiperOrigin-RevId: 654430227
Change-Id: Iae8797994d7d87bd4f013dcdc889e7494a6ad2fb
