How we manage tests that fail
The primary function of the LayoutTests is as a "regression test suite". This means that, while we care about whether a page is being rendered correctly, we care more about whether the page is being rendered the way we expect it to. In other words, we look more for changes in behavior than we do for correctness.
When the output doesn't match, there are two potential reasons for it:
- The port is performing "correctly", but the output simply won't match the generic version. The usual reason for this is for things like form controls, which are rendered differently on each platform.
- The port is performing "incorrectly" (i.e., the test is failing).
In both cases, the convention is to check in a new "-expected" file, even though that file may be codifying errors. This helps us maintain test coverage for all the other things the test is testing while we resolve the bug.
If a test is a reftest or is timing out, crashing or flaky, we can't just check in an expected file. In that case, you may need to add an entry to the TestExpectations file to green the tree (although, rolling out the offending patch is highly preferable if that's possible).
Suppressing failures using the TestExpectations file
The test expectations are listed in the file LayoutTests/TestExpectations.
The file is not ordered. Hint: Put new changes into a random spot in the file to reduce the chance of merge conflicts when landing your patch.
The syntax of the file is roughly one expectation per line. An expectation can apply to either a directory of tests, or a specific tests. Lines prefixed with "# " are treated as comments,
and blank lines are allowed as well.
The syntax of a line is roughly:
[ bugs ] [ "[" modifiers "]" ] test_name [ "[" expectations "]" ]
- Tokens are separated by whitespace
- The brackets delimiting the modifiers and expectations from the bugs and the test_name are not optional; however modifiers components is optional. In other words, if you want to specify modifiers or expectations, you must enclose them in brackets.
- Lines are expected to have one or more bug identifiers, and the linter will complain about lines missing them. Bug identifiers are of the form "webkit.org/b/12345", "crbug.com/12345", "code.google.com/p/v8/issues/detail?id=12345" or "Bug(username)"
- If no modifiers are specified, the test applies to all of the configurations applicable to that file
- Modifiers can be one or more of
- Expectations can be one or more of
Missing,NeedsRebaseline,NeedsManualRebaseline. If multiple expectations are listed, the test is considered "flaky" and any of those results will be considered as expected.
webkit.org/b/12345 [ Win Debug ] fast/html/keygen.html [ Crash ]
which indicates that the "fast/html/keygen.html" test file is expected to crash when run in the Debug configuration on Windows, and the tracking bug for this crash is bug #12345 in the webkit bug repository. Note that the test will still be run, so that we can notice if it doesn't actually crash.
Assuming you're running a debug build on Mac Lion, the following lines are all equivalent (in terms of whether the test is performed and its expected outcome):
fast/html/keygen.html [ Skip ]
fast/html/keygen.html [ WontFix ]
Bug(darin) [ Lion Debug] fast/html/keygen.html [ Skip ]
Skip and also indicates that we don't have any plans to make the test pass.
- WontFix lines go in the NeverFixTests file as we never intend to fix them. These are just for tests that only apply to some subset of the platforms we support.
Skip must be used by themselves and cannot be specified alongside
Crash or another expectation keyword.
Slow causes the test runner to give the test 5x the usual time limit to run. A given line cannot have both
Also, when parsing the file, we use two rules to figure out if an expectation line applies to the current run:
- If the configuration parameters don't match the configuration of the current run, the expectation is ignored.
- Expectations that match more of a test name are used before expectations that match less of a test name.
For example, if you had the following lines in your file, and you were running a debug build on Mac SnowLeopard:
webkit.org/b/12345 [ SnowLeopard ] fast/html [ Failure ]
webkit.org/b/12345 [ SnowLeopard ] fast/html/keygen.html [ Pass ]
webkit.org/b/12345 [ Vista ] fast/forms/submit.html [ ImageOnlyFailure ]
webkit.org/b/12345 fast/html/section-element.html [ Failure Crash ]
fast/html/article-element.html to fail with a text diff (since it is in the fast/html directory).
fast/html/keygen.html to pass (since the exact match on the test name).
fast/html/submit.html to pass (since the configuration parameters don't match).
fast/html/section-element.html to either crash or produce a text (or image and text) failure, but not time out or pass.
Again, duplicate expectations are not allowed within the file and will generate warnings.
You can verify that any changes you've made to an expectations file are correct by running:
which will cycle through all of the possible combinations of configurations looking for problems.
There are 3 keywords for rebaselineing:
- Rebaseline is used in conjunction with webkit-patch rebaseline-expectations and is not allowed to be checked in. This is how you manually do a rebaseline.
- NeedsRebaseline you commit this with your patch to indicate that the test will need to be rebaselined once the bots have cycled. The rebaseline-o-matic bot will automatically detect when the bots have cycled (by looking at the blame on the file) and do the rebaseline for you. As long as the test doesn't timeout or crash, it won't turn the bots red if it has a NeedsRebaseline expectation.
- NeedsManualRebaseline like NeedsRebaseline, but the bot won't touch it. You'll need to come through later and s/NeedsManualRebaseline/Rebaseline and then run "webkit-patch rebaseline-expectations". Mostly, you should only need to use this if your landing two-sided Chromium patches.