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 \
                                 --exit-after-n-failures 500 --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

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

Debugging crashes

It is possible to run gdb directly on the DumpRenderTree binary to debug crashing tests:

$ gdb --args <BUILD DIRECTORY>/bin/DumpRenderTree LayoutTests/fast/forms/plaintext-mode-1.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).