<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 8, 2016 at 3:17 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.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 Mon, Feb 8, 2016 at 3:12 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Feb 8, 2016 at 3:08 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Feb 1, 2016 at 10:44 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Fri, Jan 29, 2016 at 5:58 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> To clarify, it is not 128 iterations, but creating a symbol table with<br>
>> >> 128 entries -- which is a reasonable size.<br>
>> ><br>
>> ><br>
>> > We don't generally test on "realistic" sized inputs in the regression<br>
>> > suite.<br>
>> > We write targeted tests for functionality. Broad testing is done in the<br>
>> > test-suite and other integration level testing.<br>
>> ><br>
>> >><br>
>> >> Test coverage wise, it is probably the same as a 3-entry symtab.<br>
>> ><br>
>> ><br>
>> > Then let's use a 3-entry symtab.<br>
>> ><br>
>> > (why 3? Because it tests the boundaries (first and last) and one<br>
>> > "normal"<br>
>> > case of a non-boundary value - while the boundaries probably aren't<br>
>> > interesting in this algorithm, it's cheap enough to just follow that<br>
>> > common<br>
>> > practice in test case design)<br>
>><br>
>> Will update it to 3.<br>
>><br>
>> ><br>
>> > I'm also curious about the padding parameter - what does it do? Choose<br>
>> > how<br>
>> > many null characters go between each value? What effect does that<br>
>> > have/why<br>
>> > is that a tuning parameter? (understanding what it's for can help us<br>
>> > choose<br>
>> > appropriate test cases/coverage for that functionality)<br>
>><br>
>> Internal padding bytes (for alignment to 4 bytes) can be zero to 3.<br>
><br>
><br>
> Any idea what's particularly useful to test here? (does it just assert that<br>
> the parameter is [0,3] ? Or does it have well defined behavior (returning an<br>
> error code? doing something else?) outside that range? is any case more<br>
> interesting than any other - or just a simple loop for [0,Padding] done at<br>
> some point in the algorithm? Does anything test that the algorithm emitted<br>
> the right padding?)<br>
<br>
</div></div>It tests that the reader is (flexible) and capable of handing padding<br>
bytes not produced by the writer.  How many paddings should be emitted<br>
is not specified. For instance, if some producer forces 8 byte<br>
alignment, it should be handled too.</blockquote><div><br>Ah, OK - perhaps we could just test one pseudo-random (if it's really just a "while (null byte)" loop to ignore the padding - I'd probably pick 2 bytes of padding, but don't mind any small number) amount of padding to test that the reader ignores it, rather than testing several amounts of padding? Alternatively/in addition, might be good to test these features separately to make triage easier? Rather than combining compression and padding together - unless there's an interesting interaction between the two features in the implementation?<br><br>You say "padding bytes not produced by the writer" - does the writer produce zero bytes of padding, or some amount of padding that's just not the same amounts as are being tested here?<br><br>- David</div></div></div></div>