From 704105148860d6b90b009681b221a76575e5c88c Mon Sep 17 00:00:00 2001 From: Abseil Team Date: Tue, 24 May 2022 10:57:10 -0700 Subject: [PATCH] Clarify the pitfalls of EXPECT_THAT and highlight it's best practices PiperOrigin-RevId: 450721917 Change-Id: I34d63a65b7158975abd46a9a14cded75439e7e7f --- docs/reference/matchers.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/reference/matchers.md b/docs/reference/matchers.md index 0f57db47..9fb15927 100644 --- a/docs/reference/matchers.md +++ b/docs/reference/matchers.md @@ -8,9 +8,13 @@ A **matcher** matches a *single* argument. You can use it inside `ON_CALL()` or | `EXPECT_THAT(actual_value, matcher)` | Asserts that `actual_value` matches `matcher`. | | `ASSERT_THAT(actual_value, matcher)` | The same as `EXPECT_THAT(actual_value, matcher)`, except that it generates a **fatal** failure. | -{: .callout .note} -**Note:** Although equality matching via `EXPECT_THAT(actual_value, -expected_value)` is supported, prefer to make the comparison explicit via +{: .callout .warning} +**WARNING:** Equality matching via `EXPECT_THAT(actual_value, expected_value)` +is supported, however note that implicit conversions can cause surprising +results. For example, `EXPECT_THAT(some_bool, "some string")` will compile and +may pass unintentionally. + +**BEST PRACTICE:** Prefer to make the comparison explicit via `EXPECT_THAT(actual_value, Eq(expected_value))` or `EXPECT_EQ(actual_value, expected_value)`.