Vishesh Srivastava on KDE Blogs

[SoK 2026] Appium Testing for Lokalize

Vishesh Srivastava — Fri, 20 Mar 2026 00:00:00 +0000

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.

[SoK 2026] Halfway update: Appium Testing in Lokalize

Vishesh Srivastava — Sun, 08 Mar 2026 00:00:00 +0000

Hey there! I'm Vishesh Srivastava, and we're at the halfway mark of my SoK 2026 project — writing Appium-based UI tests for Lokalize. I was a bit late for the halfway mark, but we're still on track.

So what's Lokalize?

It's KDE's translation tool — the app that translators use to work with PO files and manage translation. It does its job well but it had zero UI tests. None. My job this SoK is to fix that.

The starting days (January)

My first task was Bug 514468 — where copyright year strings in PO headers would be very long like 2006, 2010, 2011, 2012, 2013, 2014, 2015, 2017, 2018, 2019, 2020, 2021 instead of the more concise 2006, 2010-2015, 2017-2021.

I was asked to write a failing test first. So I added a simplifyYearString placeholder function, wrote a unit test that expects the collapsed range output, and marked it with QEXPECT_FAIL since the actual implementation was going to be done by someone else. It was updated to expect to pass when the bug was fixed.

More importantly, this got me comfortable with KDE's setup, kde-builder, and how the testing framework works.

The main work: Appium tests (February – March)

This is where the real fun began. Lokalize had absolutely no Appium setup, so everything was built from the ground up.

First steps

My first tests were very simple. simple_open.py literally just opens Lokalize and closes it. That's the whole test. file_open.py was the next step: open the app, click File, click Open, and confirm the dialog shows up. Not much but you have to crawl before you can walk.

A bug I encountered

Here's something I found: Appium finds UI elements through accessibility properties, and Lokalize's editor text fields didn't have any (found using accessibilityinspector). So my test scripts were essentially blind — they could see menus and buttons but couldn't interact with the actual editor. I had to edit editorview.cpp to add object names and accessible names to the widgets to actually get Appium to see them.

Other KDE apps with Appium tests (Dolphin, KCalc) already had these, but nobody had needed them in Lokalize before. These were my reference for writing the code.

The workflow test (the one I'm actually proud of)

workflowtest.py is the test that simulates what a translator would actually do:

Open a .po file with two untranslated entries
Type a translation into the target field
Hit "Approve and Go Next"
Do the same for the second entry
Check if the editor tab UI was updated successfully
Check that the status bar says Not ready: 0 — meaning everything's translated
Save the file

Below is a demo of this working:

It's a proper end-to-end test.

Integrating with CMake

To make it so that these tests run along with all other tests with kde-builder --run-tests, I added a CMakeLists.txt for the appiumtests directory and added it into the project's build system behind a BUILD_APPIUM_TESTS option:

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

Now the tests integrate with the Appium tests just like they do in other KDE apps.

Next steps

Writing failing tests for bugs
Edge case tests

Final thoughts (for now)

It's been a enjoyable experience and many thanks to Finley Watson for offering great help along the way.

Halfway there. Let's see what happens next.