Version 35 (modified by 10 years ago) ( diff ) | ,
---|
DumpRenderTree is related to WebKit's layout tests and can be run with the run-webkit-tests
script.
Dependencies
You can install the dependencies with the following command:
$ Tools/efl/install-dependencies
Building WebKitTestRunner
In order to build it in a way that all expected tests pass and it does not crash, however, certain features need to be enabled when building the port.
./Tools/Scripts/build-webkit --efl [--update-efl]
Running LayoutTest
In order to run WebKitEFL's LayoutTest successfully, "exit-after-n-failuers" option should have 500 as its own value when user run layout test because at least 500 test cases are failed for now.
./Tools/Scripts/run-webkit-tests --efl --release --no-show-results \ --results-directory layout-test-results --verbose
If you wish to run a single test you can do:
./Tools/Scripts/run-webkit-tests --efl fast/forms/plaintext-mode-1.html
WebKit EFL port doesn't support WebKitEFL anymore. So, you have to add "-2" option to test WebKit2EFL.
./Tools/Scripts/run-webkit-tests --efl --release -2
Debugging crashes
It is possible to run gdb directly on the WebKitTestRunner binary to debug crashing tests:
$ TEST_RUNNER_PLUGIN_PATH= TEST_RUNNER_INJECTED_BUNDLE_FILENAME=WebKitBuild/Release/lib/libTestRunnerInjectedBundle.so ./WebKitBuild/Debug/bin/WebKitTestRunner -v LayoutTests/fast/css/at-host-cssom-crash.html
In WebKit2, the UI process will spawn new Web processes so it can be tricky to debug those with gdb. If you need to debug a crash in a WebProcess, you can use the "-webprocess-cmd-prefix=<prefix>" argument to run-webkit-tests (in debug mode only). For example, if you want the new Web processes to be executed in gdb, you can use the following command:
./Tools/Scripts/run-webkit-tests -2 --efl --webprocess-cmd-prefix="DISPLAY=:0 xterm -title WebProcess -e gdb --args" LayoutTests/fast/forms/plaintext-mode-1.html
The "xterm" is necessary or gdb will run in the current terminal, which can get particularly confusing since it's running in the background, and if you're also running the main process in gdb, won't work at all (the two instances will fight over the terminal). The DISPLAY=:0
is necessary since the xterm goes to the Xvfb otherwise.
To auto-start the web processes in the debugger, send the "run" command to the debugger:
./Tools/Scripts/run-webkit-tests -2 --efl --webprocess-cmd-prefix="DISPLAY=:0 xterm -title WebProcess -e gdb --eval-command=run --args" LayoutTests/fast/forms/plaintext-mode-1.html
If you want to do the same thing when executing the EFL MiniBrowser, you can do it by properly setting the "WEB_PROCESS_CMD_PREFIX" environment variable:
WEB_PROCESS_CMD_PREFIX="xterm -title WebProcess -e gdb --args" WebKitBuild/Debug/bin/MiniBrowser
Use PLUGIN_PROCESS_COMMAND_PREFIX in a similar manner for plugin process debugging (you may also have to use MOZ_PLUGIN_PATH to make sure the plugins you test are found).
Known issues
If all your tests are crashing, you might want to have a look at these two topics extensively discussed on the mailing list.
- If you use Ubuntu 13.04, you don't need to handle these tips.
- How to run layout tests with ATI and NVidia drivers
- How to run layout tests with X server 1.13.0 (i.e. the X server shipped on Ubuntu 12.10)
- When media tests take too long time, you need to check if pulseaudio is running as daemon. If pulseaudio daemon doesn't run, you may need to do below steps.
- sudo gpasswd -a "buildbot-user" pulse-access
- edit /etc/pulse/system.pa
- load-module module-native-protocol-unix auth-anonymous=1
- Try running pulseaudio in system mode