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.

gtest

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 WebKit 2 APIs 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 bellow 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)
{
    loadUrlSync(environment->defaultTestPageUrl());
    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)
        return;

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

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

• 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.

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.

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"

Questions

• 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.