[llvm-dev] RFC: Reconsidering adding gmock to LLVM's unittest utilities
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 4 14:25:47 PST 2017
On Wed, Jan 4, 2017 at 11:55 AM Pete Cooper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> EXPECT_THAT(actual, Eq(expected));
> EXPECT_THAT(actual, Ne(not-expected));
>
> For the cases where you have containers and other non-trivial objects, I
> completely agree that this is compelling. However, for simple cases like
> string equality I don't like the change from EXPECT_EQ(a, b) to
> EXPECT_THAT(a, Eq(b)).
>
I'd like to understand -- why do you not like it?
On one hand, I dislike it because it is longer to type and read.
On the other hand, I like it because it is more consistent and explicit
what is being *tested* and what the *expectation* is.
>
> Which brings me to what I guess is my main question. Are we going to be
> able to keep using EXPECT_EQ (and others) via gtest? Or are we going to
> slowly migrate from gtest to gmock?
>
Note that gmock is a subset of gtest, relies on it, and can't work without
it. And all of the TEST(...) stuff is strictly gtest.
It is only the EXPECT_* and ASSERT_* bits that gmock provides an
alternative for.
> I don't think you are suggesting phasing out gtest, but at the same time
> I'm not really sure why we should have both. It may be easier to move
> completely to gmock if its more powerful, even if the checks are sometimes
> more verbose for simple cases.
>
This is essentially where I am at.
If we didn't need the more expressive expectations in some cases, I would
totally stick with EXPECT_EQ and friends for consistency and simplicity.
But if the use cases for more rich and powerful matchers in test EXPECT
lines is compelling, I have a mild preference for not having two ways of
writing EXPECT_* and ASSERT_* lines, even though the simple cases are a bit
more typing. The consistency and predictability for me win out, but not by
much. =] I don't think its a huge deal either way.
I'd also be totally willing to have LLVM-specific aliases of:
EXPECT(...) -> EXPECT_THAT(...)
ASSERT(...) -> ASSERT_THAT(...)
Because these are only inside of tests, and LLVM's projects are reasonably
self contained, if saving the 5 characters helps folks, I'm OK with it.
Anyways, this is something of a detail to sort out if we want the matcher
functionality.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170104/86858244/attachment.html>
More information about the llvm-dev
mailing list