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

[Pete Cooper via llvm-dev]

> On 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 <mailto: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.
Thats all it is TBH.  Seems like we should just do "#define EXPECT_EQ(a, b) EXPECT_THAT(a, Eq(b))" or something similar.  Or perhaps it just doesn't matter that much.
> 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.
Ah ok, thanks for clarifying.
> 
> 
> 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.
Yeah, thats totally fine with me.
> 
> Anyways, this is something of a detail to sort out if we want the matcher functionality.
Sounds good.  Cheers!

Pete
> 
> -Chandler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170104/14370ad4/attachment.html>