<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 4, 2016 at 4:46 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">chandlerc added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D23156#506253" rel="noreferrer" target="_blank">https://reviews.llvm.org/D23156#506253</a>, @dblaikie wrote:<br>
<br>
> Do you need to use permutations?<br>
><br>
> So the original version tried every value in every slot against every other value in every slot.<br>
<br>
<br>
More than that, see below:<br>
<br>
> Given, say, 4 slots each with M, N, O, and P possible values, that gives us M * N * O * P test cases.<br>
<br>
<br>
So, the original version, ignoring the 3-slot special case and just focusing on the 4 slot case did:<br>
<br>
(M * N * O * P) * 4!<br>
<br>
> - but we can reasonably identify that the parsing of the value in a given slot is independent of the values in the other slots, so this now tests every value in every slot regardless of the values in other slots?<br>
<br>
>   - that gets us down to (M + N + O + P) * 4 tests (assuming 4 slots for simplicity)<br>
<br>
<br>
Correct in general. IT gets us down to: (M + N + O + P) * 4! tests.<br>
<br>
> - would it be reasonable to assume that the parsing of a value is independent of which slot it is in? So we shouldn't then test that every value can appear in every slot/ordering?<br>
<br>
<br>
It might, but that just saves 4! from this and wouldn't catch stateful bugs in the parsing. So I'm pretty happy to try and parse each entry in each position.<br>
<br>
Mostly this is because the runtime is now so fast that it seems to not matter.<br>
<br>
Does that make sense?<br></blockquote><div><br></div><div>My concern is that it seems not to matter relative to how bad this was - but I'm still pretty strongly in favor of fairly precisely testing functionality orthogonally when its implementation is orthogonal (otherwise we get into a pretty unbounded space of testing) - but I get that there's certainly a tradeoff here between just how white-box the test coverage gets.<br><br>Generally I think of a parser as being a pretty good example of highly orthogonal code - I would be really surprised if the code behaved any differently when it was parsing one of these values in one slot rather than any other. Is there something in the architecture that makes that a real risk we should be trying to mitigate?<br><br>Anyway - your call, just my 2c & I know I can go off the deep/pedantic end trying to reduce the test matrix too much sometimes, so take it with a grain of salt :)<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="https://reviews.llvm.org/D23156" rel="noreferrer" target="_blank">https://reviews.llvm.org/D23156</a><br>
<br>
<br>
<br>
</blockquote></div></div>