Sunday, 8 March 2026
@iambeastofhell:matrix.orgHey 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
.pofile 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.
ngraham
