<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 5, 2011, at 12:29 PM, Dirk Pranke wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><font class="Apple-style-span" color="#007329"><br></font>The problem with your idea is I think what brought this idea up in the<br>first place: if you just track that the test is failing using the<br>test_expectations.txt file, but don't track *how* it is failing (by<br>using something like the -failing.txt idea, or a new -expected.txt<br>file), then you cannot tell when the failing output changes, and you<br>may miss significant regressions.<br></div></blockquote></div><br><div>That's right, layout tests were designed to be regression tests rather than correctness tests. They are supposed to detect changes in behavior. Having an existing bug is not necessarily a good reason to drop test coverage.</div><div><br></div><div>I think instead of introducing a new -failing.txt concept, a better approach would be to have a way to mark in test_expectations.txt that the checked-in -expected.txt for that particular platform represents a bug. I think that is a better way to indicate the state, all in a centralized place, than using a different filename.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br></div></body></html>