<div class="gmail_quote">On Wed, May 23, 2012 at 1:25 PM, Dirk Pranke <span dir="ltr"><<a href="mailto:dpranke@chromium.org" target="_blank">dpranke@chromium.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Not so: if the tests we had had 100% coverage, then importing more<br>
tests would buy us nothing, but getting rid of the existing tests<br>
would be quite unfortunate.</blockquote><div><br></div><div>We certainly don't have 100% test coverage.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Clearly adding tests incurs some costs and probably provides some benefit; the question is when does the cost exceed the benefit?<br></blockquote><div><br></div><div>Doing anything incurs some cost. In fact, not adding a test itself incurs a risk cost of potentially taking regressions in the future that could have been caught by the test.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I am not against importing more tests per se, I think this only<br>
makes sense to evaluate on a case-by-case basis.<br></blockquote><div><br></div><div>Sure. We shouldn't be importing tests that are obviously duplicates of our existing tests.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> The only sane argument I've heard so far to gate pixel tests is that the<br>
> correctness of such tests need to be manually inspected, which requires a<br>
> lot of manual labor and is very error prone.<br>
<br>
</div>I'm assuming the above includes the ongoing maintenance cost of<br>
keeping pixel tests up to date, as well as the cost at the initial<br>
checkin.</blockquote><div><br></div><div>I'm not concerned of those. Once the correct expected result is checked in, it's pretty easy to rebaseline tests per rendering engine changes assuming people who are rebaselining tests know what they're doing.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is also the fact that the more tests we have, the more tests we<br>
have to run, and increasing cycle time by itself is a cost to developer productivity.</blockquote><div><br></div><div>Sure, but I don't think that's a valid argument for not adding tests especially since there is no way for us to mechanically test whether two tests test the same set of features or not (this is an intractable problem even in its limited form and an undecidable one in its most general form).</div>


<div><br></div><div>Also, using ref test or pixel test, etc... doesn't change the cycle time significantly so I don't understand what your argument is. Or are you suggesting that non-ref tests are somehow more redundant than ref tests? (please give us why).</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Of course, it's also potentially the case that<br>
we have to update tests from time to time, although this doesn't<br>
happen often.<br></blockquote><div><br></div><div>Because the current process is broken :) In the ideal world, we would be updating our copy of W3C tests every so often (e.g. every month or so).</div><div><br></div><div>

- Ryosuke</div><div><br></div>
</div>