[llvm-dev] RFC: Reconsidering adding gmock to LLVM's unittest utilities
Zachary Turner via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 4 14:35:34 PST 2017
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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev