<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 11:10 AM, Eugene Zelenko <span dir="ltr"><<a href="mailto:eugene.zelenko@gmail.com" target="_blank">eugene.zelenko@gmail.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="HOEnZb"><div class="h5">On Fri, Feb 19, 2016 at 11:06 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> Could we take this conversation back to the list? (better to discuss things<br>
> with everyone)<br>
><br>
> On Fri, Feb 19, 2016 at 11:02 AM, Eugene Zelenko <<a href="mailto:eugene.zelenko@gmail.com">eugene.zelenko@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Feb 19, 2016 at 10:54 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>> wrote:<br>
>> > Ah, I don't think that's the case/not the testing I'm suggesting - I<br>
>> > think<br>
>> > the std::set example is a good one to follow (& while it's laudible to<br>
>> > add<br>
>> > missing coverage, it's not a requirement & shouldn't be an impediment to<br>
>> > adding /some/ testing, especially for any new code/changes)<br>
>> ><br>
>> > You could stamp out the types with a macro to save some code (but I<br>
>> > imagine<br>
>> > the /usage/ would need to be separate, for the fixits to work properly,<br>
>> > etc)<br>
>><br>
>> Sorry, I'm not expert in testing, but anything that doesn't test real<br>
>> implementation is flawed by design for me. This is my conclusion after<br>
>> I discovered that container check didn't work with own STL<br>
>> implementation.<br>
><br>
><br>
> It's a tradeoff, to be sure - but we can't test with every STL<br>
> implementation, and even testing with one may add a lot of overhead to<br>
> tests. The same is true for other aspects of the LLVM project testing - in<br>
> our regression suite we don't test LLVM with Clang, we test LLVM and Clang<br>
> each in isolation. This ensures the testing is targeted and fast, but can<br>
> lead to divergence on the boundaries (testing that Clang produces A, but<br>
> testing that LLVM handles B, instead of A).<br>
><br>
> - David<br>
<br>
</div></div>Sure, it's not possible to test with every STL implementation, but<br>
it's reasonable to test with implementation used for particular build.<br>
If LLVM/Clang could be built with it, why not Clang-tidy regressions?<br></blockquote><div><br></div><div>They can, but it's a tradeoff as I said - makes the test much broader than is necessarily ideal. (this is the usual tradeoff between unit/feature/integration testing) I wouldn't be opposed to integration testing, but it wouldn't generally be run under "make check" (instead as part of some larger feature testing mode run on buildbots, etc) and wouldn't be a substitute for these more targeted unit-like tests.</div></div></div></div>