<div class="gmail_quote">On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler <span dir="ltr"><<a href="mailto:darin@apple.com">darin@apple.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="im">On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:<br>
<br>
</div><div class="im">> Does that apply to -expected.txt files in the base directories, or just platform-specific exceptions?<br>
<br>
</div>Base directories.<br>
<br>
Expected files contain output reflecting the behavior of WebKit at the time the test was checked in. The expected result when we re-run a test. Many expected files contain text that says “FAIL” in them. The fact that these expected results are not successes, but rather expected failures does not seem to me to be a subtle point, but one of the basic things about how these tests are set up.<br>
</blockquote><div><br></div><div>Right, it helps us keep track of where we are, so that we don't regress, and only make forward progress.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> I wonder how it is that I've been working (admittedly, mostly on tooling) in WebKit for more that two years and this is the first I'm hearing about this.<br>
<br>
</div>I’m guessing it’s because you have been working on Chrome.<br>
<br>
The Chrome project came up with a different system for testing layered on top of the original layout test machinery based on different concepts. I don’t think anyone ever discussed that system with me; I was the one who created the original layout test system, to help Dave Hyatt originally, and then later the rest of the team started using it.<br>
</blockquote><div><br></div><div>The granular annotations (more than just SKIP) in test_expectations.txt was something we introduced back when Chrome was failing a large percentage of layout tests, and we needed a system to help us triage the failures.  It was useful to distinguish tests that crash from tests that generate bad results, for example.  We then focused on the crashing tests first.</div>
<div><br></div><div>In addition, we wanted to understand how divergent we were from the standard WebKit port, and we wanted to know if we were failing to match text results or just image results.  This allowed us to measure our degree of incompatibility with standard WebKit.  We basically used this mechanism to classify differences that mattered and differences that didn't matter.</div>
<div><br></div><div>I think that if we had just checked in a bunch of port-specific "failure" expectations as -expected files, then we would have had a hard time distinguishing failures we needed to fix for compat reasons from failures that were expected (e.g., because we have different looking form controls).</div>
<div><br></div><div>I'm not sure if we are at a point now where this mechanism isn't useful, but I kind of suspect that it will always be useful.  Afterall, it is not uncommon for a code change to result in different rendering behavior between the ports.  I think it is valuable to have a measure of divergence between the various WebKit ports.  We want to minimize such divergence from a web compat point of view, of course.  Maybe the count of SKIPPED tests is enough?  But, then we suffer from not running the tests at all.  At least by annotating expected IMAGE failures, we get to know that the TEXT output is the same and that we don't expect a CRASH.</div>
<div><br></div><div>I suspect this isn't the best solution to the problem though.</div><div><br></div><div>-Darin</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
> Are there reasons we [are] doing things this way[?]<br>
<br>
Sure. The idea of the layout test framework is to check if the code is still behaving as it did when the test was created and last run; we want to detect any changes in behavior that are not expected. When there are expected changes in behavior, we change the contents of the expected results files.<br>

<br>
It seems possibly helpful to augment the test system with editorial comments about which tests show bugs that we’d want to fix. But I wouldn’t want to stop running all regression tests where the output reflects the effects of a bug or missing feature.<br>

<font color="#888888"><br>
    -- Darin<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div><br></div></div>