The WebKit project mandates that every new feature needs tests in order get accepted at the main repository. The EFL WebKit port is no different. If you are writing new APIs or modifying the existing ones, make sure that your changes are backed by a unit test.


EFL WebKit 1 and 2 uses gtest as unit test framework. We strongly recommend reading the introduction to gtest before starting. This should be enough to cover most of our testing use cases.

EFL WebKit2 API tests

Adding a new test file

Every API should have a respective test file. For adding a test for an hypothetical ewk_foobarnicator.cpp, the bootstrap should be:

  • Add your test file at: Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_foobarnicator.cpp (the prefix is test_ewk2 and not test_ewk, this was done to avoid clashes with WK1 tests)
  • Edit Source/WebKit2/PlatformEfl.cmake and add your test to the EWK2UnitTests_BINARIES list. Note that the test name is the same as the file without the .cpp extension.

Writing the new test

  • The EFL WebKit provides a gtest environment and a fixture to help you writing your tests. The fixture will create a webview ready to use.
  • The code below is a simplified example of how to test a getter of the ewk_foobarnicator API using the convenience loadUrlSync() method to load a page inline:
TEST_F(EWK2UnitTestBase, ewk_foobarnicator_bar_get)
    EXPECT_STREQ(ewk_foobarnicator_bar_get(webView()), "my expected string");
  • The same test could have be written using the normal main loop asynchronous flow:
static void onLoadProgress(void* userData, Evas_Object* webView, void* eventInfo)
    double progress = *static_cast<double*>(eventInfo);
    if (progress != 1)

    EXPECT_STREQ(ewk_foobarnicator_bar_get(webView), "my expected string");

TEST_F(EWK2UnitTestBase, ewk_foobarnicator_bar_get)
    ewk_view_uri_set(webView(), environment->defaultTestPageUrl());
    evas_object_smart_callback_add(webView(), "load,progress", onLoadProgress, this);

  • It is recommended to write one test entry at the file per function you are testing (but not enforced). The reason is because every new entry gets a new fixture and consecutively, a fresh webview. We can make sure that a bug on the function A will not interfere on the function B.
  • The test environment can be extended by per-test basis. But in order to do that, you might need to override the test main().
  • Feel free to extend the test fixture and environment if you find a convenience method/function that might be useful for other tests.
  • If you are testing a functionality that depends on a feature flag, make sure to wrap your tests around the same flag. Otherwise the test might fail or break the build when the feature is disabled.

Accessing web pages inside a test

  • As a rule of thumb, you test should rely only on locally available resources, not fetching any webpage remotely.
  • Some tests might need a Webserver to run. In this case, you can use the EWK2UnitTestServer class that will spawn a minimalistic Webserver. This server works by registering a callback for handling the requests. See the test_ewk2_cookie_manager.cpp test for more details.
  • Alternatively, if file scheme can be used, your test webpage can be stored at tests/resources and retrieved by using environment->urlForResource("somepage.html").

Running the tests

  • Every test added to the EWK2UnitTests_BINARIES list will generate an executable that you can use to run individual tests. This executable is placed at the default binary output directory (i.e. same place as the MiniBrowser, WebKitTestRunner, ImageDiff, etc).
  • You can run all the tests at once by executing the script Tools/Scripts/run-efl-tests. Give --debug as parameter if you are building debug.
  • If you are behind of proxy, you may need to set no_proxy environment such as export no_proxy="localhost,".
  • NOTE: Install xvfb: sudo apt-get install xvfb

Debugging tests

  • Tests will render by default on a offscreen memory buffer. You can override this by supplying the flag --useX11Window to your test binary to see what is going on.
  • You should do a total cleanup of the memory allocated by your tests. The reason is because we might use these tests on a future leak detector bot, running them wrapped in valgrind + memchecker (and because this is what nice developers do).

Disabling the tests

In case you don't want to build the unit tests, you can disabled them by passing the following arguments to the build script.

$ Tools/Scripts/build-webkit --efl --cmakearg="-DSHARED_CORE=ON -DENABLE_API_TESTS=OFF"

WebKit2 C API tests

Enabling new tests

WebKit2 C API tests are usually cross platform. When spotting that a new test was added to the C API test suite (located at Tools/TestWebKitAPI), it's always welcome to add it to the EFL test runner. This can be done by simple adding the test case to Tools/TestWebKitAPI/PlatformEfl.cmake following the instructions on the file. Please note that some tests might require you to write some new functionality to the test harness and also to add an entry to the injected bundle sources located at Tools/TestWebKitAPI/CMakeLists.txt.

Running and Debugging the tests

You can run and debug the tests in the same way as the EFL WebKit2 tests.


Questions regarding WebKit 2 tests can be answered at #webkit-efl at Freenode (you might want to poke tmpsantos) or at webkit-efl mailing list.

Last modified 3 years ago Last modified on May 5, 2014 2:55:34 AM