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
`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
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
Changes the behavior of UnorderedElements()/UnorderedElementsAreArray() to print items-without-matchers and matchers-without-items in the case where the actual and expected are different sizes.
PiperOrigin-RevId: 635451316
Change-Id: I2181bb28a14c14cdb577af9268d403e12e942bea
We avoid overloading or specializing `testing::Throw` as this is fundamentally a different operation than throwing the object.
However, we disable the corresponding overload of `testing::Throw` to prevent likely mistakes in the usage.
Fixes: #4412
PiperOrigin-RevId: 585745469
Change-Id: I03bb585427ce51983d914e88f2bf65a13545c920
The current implementation breaks for absl::string_view on gcc, c++14: https://godbolt.org/z/Tzd3q1fqxCloses#4391
PiperOrigin-RevId: 575853981
Change-Id: I7b782598add480eb69d4ca27ea4a4bf5f758f6a3
Some versions of MSVC provide incorrect values for the latter and rely on _MSVC_LANG instead.
Fixes#4226.
PiperOrigin-RevId: 527919195
Change-Id: Ifcca4612074f5ebc5337094426866a187f79f90a
This makes the behavior consistent when GTEST_STACK_TRACE_DEPTH is set to zero
and not: there is always vertical whitespace separating failure messages.
PiperOrigin-RevId: 518744611
Change-Id: I5b4af40633849850660504c3f497a76601d4311d
For MSVC, gmock_output_test.py output struct std::pair<int,bool>, for GCC, it's output
std::pair<int, bool>, it's not the same, my intention is getting these to be same by removing
struct for MSVC's outptu, and strip redundant space for GCC.
As a by-product,
```
#ifdef _MSC_VER
#define ERROR_DESC "class std::runtime_error"
#else
#define ERROR_DESC "std::runtime_error"
#endif
```
can be simplified to
```
#define ERROR_DESC "std::runtime_error"
```
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
This CL changes the link in the ReportUninterestingCall message from
.../gmock_cook_book.md#knowing-when-to-expect to
.../gmock_cook_book.md#knowing-when-to-expect-useoncall. This is necessary
following https://github.com/google/googletest/commit/31ff597.
PiperOrigin-RevId: 510138974
Change-Id: Ic98c84b07751d27dfc95eddbe7874f76d68b456f
Nothing defines GTEST_USES_PCRE anymore. It was only meant for
internal use, so nothing public should be relying on it:
https://github.com/google/googletest/issues/2735#issuecomment-644849438.
Found when compiling with "-Wundef".
Fixes#2735.
PiperOrigin-RevId: 507823660
Change-Id: Ie19e576ff01dc3b16381338578ece92adccfc09b
Prior to this change we had a mixture of pragmas and
GTEST_DISABLE_MSC_WARNINGS; this change consolidates all instances
to use the macros.
PiperOrigin-RevId: 505786926
Change-Id: I2be8f6304387393995081af42ed32c2ad1bba5a7
warning C4244: 'initializing': conversion from 'int' to 'short', possible
loss of data
PiperOrigin-RevId: 505774670
Change-Id: I3524040334a4b265bae12cfacdd2b615cbb1cfc8
These files were formatted with automated tools. The remaining Python
files require some manual fix ups, so they will be fixed separately.
PiperOrigin-RevId: 504579820
Change-Id: I3923bd414bffe3ded6163ec496cd09ace3951928
In #4113 a user says Max clashes with a macro. Since it is only used in
a test, use std::numeric_limits::max() instead.
Note that in headers, the macro issue can be mitigated with
parenthesis like this: `(std::numeric_limits<T>::max)()`
PiperOrigin-RevId: 504284906
Change-Id: Ibf430caec1a6afdf6b303534fec6a4fd00a6373f
