Replace an internal link to AbslStringify's documentation with the equivalent public link.
PiperOrigin-RevId: 779085254
Change-Id: I2cbd2b6262a5ced06f166d4fcc7c08796e5a60af
There are two cases that prompt this behavior:
- All test cases in the binary are disabled.
- There are more shards defined than test cases, so some shards are empty.
The result in each case is the same: the test runner needs to spin up
additional processes that do nothing, which is wasteful, especially when tests
need expensive resources.
PiperOrigin-RevId: 769176856
Change-Id: Ifa399a0b7b68e4add5a94ca148b32b2938a8666d
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
Abseil Team