<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Writing a more thought-out reply....</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Nov 12, 2013 at 9:16 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank" class="cremed">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Nov 12, 2013, at 7:04 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>
<br>
> 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.<br>

<br>
</div>Personally, I rather not do this, without very clear and compelling reasons.<br>
<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm not really excited about dragging another out of tree project in unless there is a compelling reason to do so.<br></blockquote><div><br></div><div>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.</div>
</div></div></div>