[LLVMdev] Any objections to my importing GoogleMock to go with GoogleTest in LLVM?

Chandler Carruth chandlerc at google.com
Thu Nov 14 03:16:31 PST 2013


Writing a more thought-out reply....

On Tue, Nov 12, 2013 at 9:16 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Nov 12, 2013, at 7:04 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> > I have some concrete use cases in testing the pass manager where it will
> allow the tests of this API to be more thorough, less verbose, and easier
> to maintain. I'm not claiming to be the biggest fan of some features in
> GoogleMock, but on the whole, I think it's better than the alternative and
> will allow more careful testing of C++ APIs where the interesting part is
> the API itself.
>
> Personally, I rather not do this, without very clear and compelling
> reasons.
>
> I understand that this could be very useful for your bringup (and so could
> be very useful locally), but once the passmanager is the default, it will
> get lost of in-tree testing by just about everything in the compiler.
>

I would much rather have it in the tree than just use it locally. I think
it will also make subsequent iterations much easier to test and show are
correct. I think it would also allow significantly more precise regression
testing in the future.

This also isn't the first time I've wanted it in LLVM and in Clang. It's
just the first time I've been working on something large enoguh to feel
like importing it would be worth the cost.

My feeling is that both gtest and gmock suffer from the same flaw: they can
easily be overused or misused in circumstances where there are clearly
better ways to go about things. However, I feel like within LLVM we have
been really good at pushing back against that and using integration tests
with excellent tool support (how I love FileCheck) much more prevalently.
As long as we continue to code review unittests with an eye toward
skepticism, I think there is very little risk of things getting out of
hand. I think adding gmock to gtest doesn't shift that risk in any
significant way.

However, when we are adding interfaces or generic utilities to LLVM
(admittedly, not the common case) I don't think we do ourselves any favors
by using only half of the available tools to write unit tests for them.


>
> I'm not really excited about dragging another out of tree project in
> unless there is a compelling reason to do so.
>

It helps that gmock is a sibling of gtest. It doesn't really pull in very
much new stuff and like gtest it has strictly managed its dependencies down
to zero. I'm happy to do the importing, the fixing, and to even police
unittests for misuses. I actually don't expect it to be widely used, but I
expect it to make tests significantly more comprehensible and brief in the
limited cases where it applies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131114/37e7fc86/attachment.html>


More information about the llvm-dev mailing list