<div dir="ltr"><div class="gmail_extra">I'm sorry I even sent the original email.</div><div class="gmail_extra"><br></div><div class="gmail_extra">To be clear, I am trying to write some specific code, and gmock would make my life significantly easier. I'm not really trying to start or win a debate about how to write tests in LLVM. I think that debate should be held around tests, not around abstract libraries if it is even worth having at all. I am a big believer in giving people a powerful set of tools and asking that they use only those appropriate for a particular situation, and using code review to help uphold those standards.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Despite the increasingly polarized discussion here, I am not actually in serious disagreement with any of the principles or high level sentiments expressed by folks like Chris, Renato, and to a limited extent Alp. (Limited because he got off on a tangent that isn't even relevant about some kind of corporate interest in freezing APIs. That is total bunk.) Mostly, I think that these are all valid concerns and that there is a tradeoff that has to be assessed on a case-by-case basis. Others clearly see it as a bit more black and white. Totally OK, as reasonable folks can disagree here.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Ultimately, I'm really uninterested in a time wasting philosophical debate at this stage. I didn't want to start one.</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Clearly people are afraid of the tests that might be written with gmock. OK, I will keep significant amounts of testing out of tree while doing development. I find this silly and a waste of everyone's time, but I really see these as a tool to aid my development and maybe my code reviewers' understanding of the code. If there is some long-term maintenance burden perceived by having such tests around, I'll happily never commit them.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Let's get back to writing and reviewing code rather than trying to lecture each other on how to write better tests (and I include my own emails in that set, I'm completely guilty of this as well).</div>
<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 1:47 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank" class="cremed">renato.golin@linaro.org</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">On 15 November 2013 04:38, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span style="color:rgb(34,34,34)">Right, validating my assertion that while TDD and unit testing are good in general, they may not be right for LLVM.  In LLVM, we have mature tests of other sorts, as well as a strong process of review.</span></div>

</div></blockquote><div><br></div></div><div>While I understand the value of TDD, I have to agree with Chris, here.</div><div><br></div><div>I have been bitten by having to write silly boundary checks tests that the code would never allow, and getting 100% test coverage (of lines AND branches), only to realize that a test engineer could break my new feature in many different ways by misusing it on a command-line level.</div>

<div><br></div><div>I personally think we'd have a much better use of time by making the MI layer dumpable and re-readable, so we could create lots of very specific low-level tests, than having yet-another unit-test infrastructure.</div>

<div><br></div><div>The only place I think that unit-tests are worthy is on base libraries (APFLoat, APInt, containers, basic algorithms), and for that, you need nothing special.</div></blockquote></div><br><br></div></div>