[llvm-dev] RFC: Reconsidering adding gmock to LLVM's unittest utilities

[Zachary Turner via llvm-dev]

Alongside this, can we come up with a place in the codebase to put shared
matchers?  I almost tried to solve this previously when i wanted to unit
test some functions returning llvm::Error and/or llvm::Expected objects.
Because if a function returns an error, you have to consume it before you
continue or the unit test asserts.  So this is an example of where you
might to have a shared matcher that anyone can use.  It seems like there
could be other examples of wanting shared matchers as well, so perhaps it's
worth adding a folder somewhere under llvm/Unittests that we can provide
some support matchers for commonly used things.

On Wed, Jan 4, 2017 at 2:25 PM Chandler Carruth <chandlerc at google.com>
wrote:

> 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/f3bda32d/attachment.html>