<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 14, 2013 at 10:58 AM, 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 style="word-wrap:break-word"><div class="im">On Nov 14, 2013, at 3:16 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>> wrote:</div>
<div><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></blockquote><div><br></div></div><div>I agree in principle, but it leads me to a different conclusion.  We have other great testing support, which means that the mocking *should* only be used sparingly.  Given that it will not be used much, the cost of carrying it around (and for people to learn how to use/maintain it) is high.</div>
</div></div></blockquote><div><br></div><div>I think the cost of carrying it around is essentially zero. I'm happy to do any of the maintenance. People who don't know how to use it or want to learn how to use it don't need to use it. If it isn't making their job of writing tests sufficiently easier to justify, then they don't use it. I see this as a good pattern.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I’ve said this before, but I’m not a fan of our current use of gtest for unit testing.  I have never had the unit tests catch a bug, but I have had to update the tests countless times.  At least for my purposes, the unit tests cause significantly more harm than good - and it certainly isn’t because I write perfect code. :-)</div>
</div></div></blockquote><div><br></div><div>I seem to recall code review spotting a bug that would have been caught by a unittest were one written. Also, I don't see a lot of patches going in over the last 2 years that had to re-shuffle unittests. They happen, but they are very rare. So while I agree this can be a problem, I don't see it being a problem in practice.</div>
<div><br></div><div>Even so, you aren't the only one we're trying to optimize for. A lot of people have written unittests using the framework, and I think the incremental cost of making it a slightly more powerful framework (by adding one complementary library) is really low.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>There is definitely a culture/religion around testing and TDD, and I am well aware that many projects don’t have proper tests (which LLVM doesn’t suffer from).  However, there is a pragmatic balance to be struck here, and I personally think that adding gmock and pushing the unit tests stuff even further is a bad use of testing time (i.e., increases test cycles for make check) and maintenance time (updating tests given that we don’t have a stable API).</div>
</div></div></blockquote><div><br></div><div>These two things (adding gmock and pushing unittests further) are not necessarily related, and I don't plan to do the latter. I'm asking if doing the former would cause significant problems for any consumers of LLVM, and I don't hear any statements to that effect except for David Chisnall's which I responded to specifically.</div>
<div><br></div><div>I'm not trying to make LLVM use unittests everywhere, I'm just trying to get a tool added to the toolbox so that a unittest I'm already writing can be written more simply and in a more maintainable fashion.</div>
</div></div></div>