[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:


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

-------------- 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