Version 7 (modified by 13 years ago) ( diff ) | ,
---|
new-run-webkit-tests
new-run-webkit-tests
(also known as NRWT) is a replacement for the original run-webkit-tests
script that was written in Perl. The new script is written in Python and leverages much of the extensive Python infrastructure we have built up over the intervening years. It has a much more extensive unit test infrastructure and will hopefully be easier to maintain than the old script (time will tell).
In addition, NRWT has the ability to run the layout tests in parallel using multiple DumpRenderTrees (or WebkitTestRunners), much strong features for reporting test failures and managing expected failures, and integration with various dashboards.
This page describes how to run NRWT.
See also
- HackingOnNewRunWebKitTests for information on modifying or hacking on NRWT.
- TestExpectations for information of managing the expected results of test runs.
- LayoutTestsSearchPath for information on how a given port determines which results to use for a test.
Running NRWT
NRWT is designed to be run both directly by developers working in a terminal window, or by the buildbots. It supports a large number of command line options to customize the behavior and the output; only a few of the most commonly used options are mentioned here.
The complete list of options is given by new-run-webkit-tests --help
and new-run-webkit-tests --help-printing
.
Basic
NRWT uses the concept of a "platform" to determine which WebKit port / implementation you are attempting to test. Where possible, it picks a default based on the operating system you are running on and the default configuration you have set (if any). However, sometimes you have to give it hints.
By default, when run interactively in a terminal or console window, NRWT attempts to be fairly terse. It will display one line of output on screen, and update that in place with events as the test run occurs. If unexpected things happen (e.g., tests fails that aren't expected to fail), they are printed out as they happen, and then summarized again at the end. If everything passes, it will print a message saying so. Also, it returns the number of unexpected test failures in the exit code for the process.
Examples
Starting up initially
% new-run-webkit-tests Collecting tests ...
(this may take a few seconds, during which time other message may be displayed, like "checking build", "parsing expectations", etc. will be displayed.
Eventually the tests will start running, and you'll get something resembling a progress meter:
% new-run-webkit-tests Testing (3%): 863 ran as expected, 0 didn't, 24080 left
and when the test completes, you'll get output something like:
% new-run-webkit-tests animations/animation-direction-normal.html -> unexpected text diff mismatch compositing/reflections/nested-reflection-animated.html -> unexpected text diff mismatch Retrying 2 unexpected failure(s) ... animations/animation-direction-normal.html -> unexpected text diff mismatch compositing/reflections/nested-reflection-animated.html -> unexpected text diff mismatch 24894 tests ran as expected, 2 didn't: Regressions: Unexpected text diff mismatch : (10) animations/animation-direction-normal.html = TEXT compositing/reflections/nested-reflection-animated.html = TEXT % echo $? 2 %
In addition, by default, a web browser will be opened to an HTML page displaying the tests that failed, and links to the output from the tests. You can notice a few things about this test output:
- Tests that fail are automatically retried, to see if the failure was "flaky" and only happens some of the time. A flaky failure (one that fails then passing during the retry is reported on screen, but does not count as an actual failure.
- The retries are all done serially in a single thread, to avoid any load-related or ordering-related issues that might be contributing to the flakiness.
- The test that failed and the type of test failure that happened are displayed in such a way as to be directly copied into the test_expectations.txt file.