[SoK 2026] Appium Testing for Lokalize

Hey there! I'm Vishesh Srivastava, and this is the full write-up for my SoK 2026 project: adding Appium-based UI tests to Lokalize.

So what's Lokalize?

It's KDE's translation tool - the app translators use to work with PO files and manage translation projects. It already had unit tests, but no UI tests. So the goal of this project was to setup a UI testing framework using Appium.

The first task: Bug 514468

Before Appium work started, my first task was Bug 514468. The issue was that copyright year strings in PO headers could become very long, like:

2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021

instead of the shorter:

2006, 2010-2015, 2017-2021

I was asked to write a failing test first, so I added a placeholder simplifyYearString function and wrote a unit test for the expected collapsed output. At first it was pushed with QEXPECT_FAIL, since the actual implementation was meant to be done separately.

This was small compared to the main project, but it helped me get comfortable with setting up KDE's build system and how tests are added to Lokalize.

Building the Appium setup from scratch

Lokalize had no Appium setup at all, so this part started from zero.

The first tests were simple:

• simple_open.py just opens Lokalize and closes it
• file_open.py opens the File menu and checks that the open dialog path works
• workflowtest.py simulates an actual translator workflow

That last one was the main test I was aiming for. It opens a .po file with untranslated entries, types translations into the editor, uses "Approve and Go Next", checks that the UI updates properly, verifies the status bar reaches Not ready: 0, and finally saves the file.

That made it a proper end-to-end test.

Problem encountered in the last test

Appium depends on accessibility information to find and interact with widgets. Lokalize's editor fields did not expose accessibility ids for Appium to call them (found using accessibilityinspector).

So I had to make changes in editorview.cpp to add object names and accessible names to the widgets. Without that, the test scripts could open the app and click menus, but they were basically blind when it came to the translation editor.

Other KDE apps with Appium tests, like Dolphin and KCalc, had tests which used these and were useful references here.

Below is a demo of this working:

Making it run with the rest of the test suite

The next step was integrating the Appium tests into CMake so they could run as part of Lokalize's normal test flow.

I added an appiumtests/CMakeLists.txt and a BUILD_APPIUM_TESTS option, so the tests can be enabled and run through the normal KDE tooling:

kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options="-DBUILD_APPIUM_TESTS=ON"

That was important because UI tests are much less useful if they live outside the project's regular test workflow. The BUILD_APPIUM_TESTS option was kept because it was not advised to run Appium tests in the CI/CD.

Another issue: Making the tests independent of the local user setup

One issue was that on opening, Lokalize asked for a name and email address which I was earlier typing manually. This was undesired since tests had to be run without user intervention.

So I added a file test_support.py, that creates a temporary config directory, writes a minimal lokalizerc, and launches Lokalize with that isolated configuration. That way the tests do not depend on my own existing settings or require any user input.

I also reused that helper across the test files so they stopped repeating the same Appium setup code again and again.

Writing a failing bug test

After the main workflow test, I also added another Appium test for a real UI bug: after closing a project, translational tab menus should become disabled.

This test is in project_close.py. It opens a project, closes it, and then checks that menus like Edit, Go, and Sync are disabled.

Fixing how the tests are executed

At first, the Appium tests were being discovered and registered individually in CMake. The next task was to run them from a single run_all.py runner. Now all the tests use a single KWin instance like they do in other projects like Dolphin.

This also makes writing new tests simpler since adding a test just means adding a new line in the run_all.py. So instead of CMake looping over every Python file, it now calls the runner once.

There was also one annoying issue here: --run-tests was reporting success even when one of the Appium tests had failed when run manually. Because of that, I had to return sys.exit(1) explicitly from the runner when the test result was not successful. Without that, the tests looked successful even after failing.

Below is a demo of this working:

Outcomes achieved

By the end of the project, Lokalize had:

• a working Appium test setup
• basic tests for startup and opening files
• a full workflow test covering translation editing and saving
• helper files to make tests cleaner and independent of local user config
• integration into the normal test system through CMake
• a single test runner file
• documentation on how to run/write tests.

Final thoughts

This was a really enjoyable project. I got to work on Appium testing, the KDE build system, and a bit of bug hunting.

Many thanks to Finley Watson for his guidance throughout the project and for helping whenever I got stuck.

The best part for me is that the work is extendible. New Appium tests can be added without rebuilding the whole setup from scratch, which was the main point of the project in the first place.