Googletest export
Update explanation of `EXPECT_EQ(NULL, ptr)` in FAQ PiperOrigin-RevId: 364626422
This commit is contained in:
parent
53cc7cd1ec
commit
4595745f72
28
docs/faq.md
28
docs/faq.md
@ -60,9 +60,10 @@ the rule.
|
|||||||
|
|
||||||
## Why does googletest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`?
|
## Why does googletest support `EXPECT_EQ(NULL, ptr)` and `ASSERT_EQ(NULL, ptr)` but not `EXPECT_NE(NULL, ptr)` and `ASSERT_NE(NULL, ptr)`?
|
||||||
|
|
||||||
First of all you can use `EXPECT_NE(nullptr, ptr)` and `ASSERT_NE(nullptr,
|
First of all, you can use `nullptr` with each of these macros, e.g.
|
||||||
ptr)`. This is the preferred syntax in the style guide because nullptr does not
|
`EXPECT_EQ(ptr, nullptr)`, `EXPECT_NE(ptr, nullptr)`, `ASSERT_EQ(ptr, nullptr)`,
|
||||||
have the type problems that NULL does. Which is why NULL does not work.
|
`ASSERT_NE(ptr, nullptr)`. This is the preferred syntax in the style guide
|
||||||
|
because `nullptr` does not have the type problems that `NULL` does.
|
||||||
|
|
||||||
Due to some peculiarity of C++, it requires some non-trivial template meta
|
Due to some peculiarity of C++, it requires some non-trivial template meta
|
||||||
programming tricks to support using `NULL` as an argument of the `EXPECT_XX()`
|
programming tricks to support using `NULL` as an argument of the `EXPECT_XX()`
|
||||||
@ -70,22 +71,21 @@ and `ASSERT_XX()` macros. Therefore we only do it where it's most needed
|
|||||||
(otherwise we make the implementation of googletest harder to maintain and more
|
(otherwise we make the implementation of googletest harder to maintain and more
|
||||||
error-prone than necessary).
|
error-prone than necessary).
|
||||||
|
|
||||||
The `EXPECT_EQ()` macro takes the *expected* value as its first argument and the
|
Historically, the `EXPECT_EQ()` macro took the *expected* value as its first
|
||||||
*actual* value as the second. It's reasonable that someone wants to write
|
argument and the *actual* value as the second, though this argument order is now
|
||||||
`EXPECT_EQ(NULL, some_expression)`, and this indeed was requested several times.
|
discouraged. It was reasonable that someone wanted
|
||||||
Therefore we implemented it.
|
to write `EXPECT_EQ(NULL, some_expression)`, and this indeed was requested
|
||||||
|
several times. Therefore we implemented it.
|
||||||
|
|
||||||
The need for `EXPECT_NE(NULL, ptr)` isn't nearly as strong. When the assertion
|
The need for `EXPECT_NE(NULL, ptr)` wasn't nearly as strong. When the assertion
|
||||||
fails, you already know that `ptr` must be `NULL`, so it doesn't add any
|
fails, you already know that `ptr` must be `NULL`, so it doesn't add any
|
||||||
information to print `ptr` in this case. That means `EXPECT_TRUE(ptr != NULL)`
|
information to print `ptr` in this case. That means `EXPECT_TRUE(ptr != NULL)`
|
||||||
works just as well.
|
works just as well.
|
||||||
|
|
||||||
If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'll have to
|
If we were to support `EXPECT_NE(NULL, ptr)`, for consistency we'd have to
|
||||||
support `EXPECT_NE(ptr, NULL)` as well, as unlike `EXPECT_EQ`, we don't have a
|
support `EXPECT_NE(ptr, NULL)` as well. This means using the template meta
|
||||||
convention on the order of the two arguments for `EXPECT_NE`. This means using
|
programming tricks twice in the implementation, making it even harder to
|
||||||
the template meta programming tricks twice in the implementation, making it even
|
understand and maintain. We believe the benefit doesn't justify the cost.
|
||||||
harder to understand and maintain. We believe the benefit doesn't justify the
|
|
||||||
cost.
|
|
||||||
|
|
||||||
Finally, with the growth of the gMock matcher library, we are encouraging people
|
Finally, with the growth of the gMock matcher library, we are encouraging people
|
||||||
to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One
|
to use the unified `EXPECT_THAT(value, matcher)` syntax more often in tests. One
|
||||||
|
Loading…
Reference in New Issue
Block a user