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
to fail the test program if no test case is linked in
(a common programmer mistake).
PiperOrigin-RevId: 730571311
Change-Id: I1dab04adfe35581274d0b4ec79a017014d50e1ea
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
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
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
`EXPECT_...` statements can be used inside matcher definitions – this is an important option that is glossed over in this documentation. Users should definitely be aware of this option, since writing custom messages to the `result_listener` can be very cumbersome (and unnecessary) sometimes.
This change adds a relevant example and includes the associated error message it provides on failure.
PiperOrigin-RevId: 630206661
Change-Id: Idee00ba77ce3c1245597aa082f9cd0efff16aceb
The CtorVsSetUp section of the FAQ says that constructors and destructors should be preferred over SetUp() and TearDown(), because they will automatically chain up to the fixture's base class, whereas for methods the user must remember to add the chaining manually.
PiperOrigin-RevId: 624273474
Change-Id: Ida41aae193d417eaf996587c7ae1a0099a8cab32
The requirement is vaguely documented by "Only the return value of the last action in the sequence will be used.".
However, this can be misleading, as users could potentially expect default-constructed values to be returned in absence of a matching return type.
PiperOrigin-RevId: 570450839
Change-Id: Ibd98a6e6b2aaf2a8cfc15ed6aeab442526eab98e
* These long-dead variants of the proto matchers don't exist in the current version of Googletest.
* No evidence of external usage: [the only external references I see](https://www.google.com/search?q=%22protocolmessageequals%22+OR+%22protocolmessageequals%22) are copies of this guide. Possibly they were already removed by the time Googletest was publicly released.
PiperOrigin-RevId: 565358401
Change-Id: I61379b7333fa8ee19cd5520caedf2c539f54c2d7
From the CMake 3.27 release notes:
Compatibility with versions of CMake older than 3.5 is now
deprecated and will be removed from a future version. Calls to
cmake_minimum_required() or cmake_policy() that set the policy
version to an older value now issue a deprecation diagnostic.
This PR also removes manually setting policy CMP0048. This is
redundant since the CMake min is already 3.X
