Tests marked as SKIP in TestExpectations (in Blink repo) won't be run at all, generally because they cause some intractable tool error. To force one of them to be run, either rename that file or specify the skipped test as the only one on the command line (see below).

To run only some of the tests, specify their directories or filenames as arguments to run_webkit_tests.sh relative to the layout test directory (/trunk/third_party/WebKit/LayoutTests). For example, to run the fast form tests, use

Or you could use

as a shorthand.

As a final quick-but-less-robust alternative, you can also just use the test_shell executable to run specific tests by using (for Windows)

as in

but this requires a manual diff against expected results, because the shell doesn't do it for you.

To see a complete list of arguments supported by run_webkit_tests.sh, run run_webkit_tests.sh --help.

Linux Note: We try to match the windows render tree output exactly by matching font metrics and widget metrics.   If there's a difference in the render tree output, we should see if we can avoid rebaselining by improving our font metrics.  For additional information on Linux Layout Tests, please see http://code.google.com/p/chromium/wiki/LayoutTestsLinux.

Mac Note: While the tests are running, a bunch of Appearance settings are overridden for you so the right type of scroll bars, colors, etc. are used.  Your main display's "Color Profile" is also changed to make sure color correction by ColorSync matches what is expected in the pixel tests.  The change is noticeable, how much depends on the normal level of correction for your display.  The tests do their best to restore your setting when done, but if you're left in the wrong state, you can manually reset it by going to System Preferences -> Displays -> Color and selecting the "right" value.

Success and Failure

Tests that use a HTTP Server

HTTP tests use a locally running HTTP server to run (lighttpd on Windows, Apache elsewhere). You don't need any special configuration to run these, but you should make sure the server is not already running. As a rule, if the test is in an http directory, it will run off the server. If you want to run various tests manually while the local http server is running, note that it exposes different test suites on different ports. For example, all tests are available via port 8081, but the webkit tests are available via port 8000 (8443 for SSL) and the pending tests are available via port 9000 (9443 for SSL).

If you run the tests using run_webkit_tests.sh or .py, the server will be started automatically. To run the server manually:

(Note that you need to have python in your path to run this by hand; we don't provide a wrapper script.

To kill the server, run run-blink-httpd --server stop, or just use taskkill or the Task Manager on Windows, and killall or Activity Monitor on MacOS.

For convenience, you can also use src/webkit/tools/layout_tests/run_http_server.sh to start and stop the server which calls through to the run-blink-httpd script in the Tools/Scripts directory.

If you get errors while running the tests that look like this:

1. Take a look at the result. New tests come in with every WebKit merge, and sometimes we just need to rebaseline them (see below) to account for acceptable differences between Chromium and Safari.
• Load the test into a trunk Chrome or test_shell build and look at its result. (For tests in the http/ directory, start the http server first. See above. Navigate to http://localhost:8000/ and proceed from there.) The best tests describe what they're looking for, but not all do, and sometimes things they're not explicitly testing are still broken.  Compare it to Safari, Firefox, and IE if necessary to see if it's correct. If you're still not sure, find the person who knows the most about it and ask.
• Some tests only work properly in test_shell, not Chrome, because they rely on extra APIs exposed there. So try that too.
• Some tests only work properly when they're run in the layout-test framework, not when they're loaded into test_shell directly. The test should mention that in its visible text, but not all do. So try that too. See "Running the tests", above.
2. If you think the test is correct, confirm your suspicion by looking at the diffs between the expected result and the actual one.
• Make sure that the diffs reported aren't important. Small differences in spacing or box sizes are often unimportant, especially around fonts and form controls. Differences in wording of JS error messages are also usually acceptable.
• $ ./run_webkit_tests.sh path/to/your/test.html --full-results-html will produce a page including links to the expected result, actual result, and diff.
• Add the --sources option to run_webkit_tests.sh to see exactly which expected result it's comparing to (a file next to the test, something in platform/mac/, something in platform/chromium-win/, etc.)
• If you're still sure it's correct, rebaseline the test (see below).  Otherwise...
3. If you're lucky, your test is one that runs properly when you navigate to it in test_shell normally. In that case, build the Debug test_shell project, fire it up in your favorite debugger (test_shell is single-process), and load the test file either from a file:// URL or by starting at the "WebKit Tests" link on the test_shell start page.
• You'll probably be starting and stopping the test_shell a lot. In VS, to save navigating to the test every time, you can set the URL to your test (file: or http:) as the command argument in the Debugging section of the test_shell project Properties.
• If your test contains a JS call, DOM manipulation, or other distinctive piece of code that you think is failing, search for that in the Chrome solution. That's a good place to put a starting breakpoint to start tracking down the issue.
• Otherwise, you're running in a standard message loop just like in Chrome.  If you have no other information, set a breakpoint on page load.
4. If your test only works in full layout-test mode, or if you find it simpler to debug without all the overhead of an interactive session, start the test_shell with the command-line flag --layout-tests, followed by the URL (file: or http:) to your test.
• In VS, you can do this in the Debugging section of the test_shell project Properties.
• Now you're running with exactly the same API, theme, and other setup that the layout tests use.
• Again, if your test contains a JS call, DOM manipulation, or other distinctive piece of code that you think is failing, search for that in the Chrome solution. That's a good place to put a starting breakpoint to start tracking down the issue.
• If you can't find any better place to set a breakpoint, start at the TestShell::RunFileTest() call in test_shell_main.cc, or at shell->LoadURL() within RunFileTest() in test_shell_win.cc.
5. Debug as usual. Once you've gotten this far, the failing layout test is just a (hopefully) reduced test case that exposes a problem.

• Check the layout-test history page to see how a test did in the most recent ~100 builds on each builder (as long as the page is being updated regularly). (This page is only available from within Google for now, but it will be fixed up and made public as soon as possible. In the meantime, anyone with access will be happy to look up your test for you.)
• A timeout will often also be a text mismatch, since the wrapper script kills the test_shell before it has a chance to finish. The exception is if the test finishes loading properly, but somehow hangs before it outputs the bit of text that tells the wrapper it's done.
• Why might a test fail (or crash, or timeout) on the buildbot, but pass on your local machine?
• If the test finishes locally but is slow, more than 10 seconds or so, that would be why it's called a timeout on the bot.
• Otherwise, try running it as part of a set of tests; it's possible that a test one or two (or ten) before this one is corrupting something that makes this one fail.
• If it consistently works locally, make sure your environment looks like the one on the bot (look at the top of the stdio for the webkit_tests step to see all the environment variables and so on).
• If none of that helps, and you have access to the bot itself, you may have to log in there and see if you can reproduce the problem manually.

To automatically re-baseline tests across all Chromium platforms, using the buildbot results, see the Rebaselining Tool. Alternatively, to manually run and test and rebaseline it on your workstation, read on.

By default, text-only tests (ones that call layoutTestController.dumpAsText()) produce only text results. Other tests produce both new text results and new image results (the image baseline comprises two files, -expected.png and -expected.checksum). So you'll need either one or three -expected.* files in your new baseline, depending on whether you have a text-only test or not. If you enable the --no-pixel-tests, only new text results will be produced, even for tests that do image comparisons.

The above command will generate a new baseline for LayoutTests/foo/bar/test.html and put the output files in the right place, e.g.  src/third_party/WebKit/LayoutTests/platform/chromium-win/LayoutTests/foo/bar/test-expected.{txt,png,checksum}

When you rebaseline a test, make sure your commit description explains why the test is being re-baselined.  If this is a special case (i.e., something we've decided to be different with upstream), please put a README file next to the new expected output explaining the difference.

Known Issues

• Windows & Linux : Do not copy and paste while the layout tests are running, as it may interfere with the editing/pasteboard and other clipboard-related tests (Mac tests swizzle NSClipboard to avoid any conflicts).
• If QuickTime is not installed, the plugin tests fast/dom/object-embed-plugin-scripting.html and plugins/embed-attributes-setting.html are expected to fail.
• If Java is not installed, some tests will fail.
• Mac: command line option --gdb is required to use gdb on TestShell. This prevents TestShell from trying hard to not hammer on Crash Reporter.