{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigboppxna3c2yk36ra77czqxb7q7hrmipq5ldbtvtumjodehjkl2u",
    "uri": "at://did:plc:6hbglz6d23ddtbkjolxkk6tk/app.bsky.feed.post/3mhfmehc57p62"
  },
  "path": "/2026/03/08/sok-appium-testing-lokalize-halfway/",
  "publishedAt": "2026-03-08T00:00:00.000Z",
  "site": "https://blogs.kde.org",
  "tags": [
    "Lokalize",
    "Bug 514468",
    "accessibilityinspector",
    "Finley Watson"
  ],
  "textContent": "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.\n\n## So what's Lokalize?\n\nIt'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.\n\n## The starting days (January)\n\nMy 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`.\n\nI 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.\n\nMore importantly, this got me comfortable with KDE's setup, kde-builder, and how the testing framework works.\n\n## The main work: Appium tests (February – March)\n\nThis is where the real fun began. Lokalize had absolutely no Appium setup, so everything was built from the ground up.\n\n### First steps\n\nMy 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.\n\n### A bug I encountered\n\nHere'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.\n\nOther 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.\n\n### The workflow test (the one I'm actually proud of)\n\n`workflowtest.py` is the test that simulates what a translator would actually do:\n\n  1. Open a `.po` file with two untranslated entries\n  2. Type a translation into the target field\n  3. Hit \"Approve and Go Next\"\n  4. Do the same for the second entry\n  5. Check if the editor tab UI was updated successfully\n  6. Check that the status bar says `Not ready: 0` — meaning everything's translated\n  7. Save the file\n\n\n\nBelow is a demo of this working:\n\nIt's a proper end-to-end test.\n\n### Integrating with CMake\n\nTo 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:\n\n\n    kde-builder --run-tests lokalize --no-include-dependencies --no-src --cmake-options=\"-DBUILD_APPIUM_TESTS=ON\"\n\n\nNow the tests integrate with the Appium tests just like they do in other KDE apps.\n\n## Next steps\n\n  * Writing failing tests for bugs\n  * Edge case tests\n\n\n\n## Final thoughts (for now)\n\nIt's been a enjoyable experience and many thanks to Finley Watson for offering great help along the way.\n\nHalfway there. Let's see what happens next.",
  "title": "[SoK 2026] Halfway update: Appium Testing in Lokalize"
}