Cool initiative! I also could recommend similar projects related to Qt, UI and Appium-based testing to take a look for a reference. It's from the local company which maintains Sailfish fork called Aurora here at github: https://github.com/omprussia
- appium — Appium patch to add an additional platform to the platforms list - appium-aurora-driver — a js-based driver for Appium (that later could be used via http from the python for example) - appium-aurora — alpine and ubuntu Dockerfiles to reproduce - aurora-test-example — python test example (Aurora-specific) - qapreload — appium-related library that could be injected into the Qt-based application for tests automation - qainspector — Qt/QML GUI client to be used with qapreload library to inspect elements tree of a Qt-based application ср, 10 авг. 2022 г. в 13:47, Nicolas Fella <nicolas.fe...@gmx.de>: > Am 10.08.22 um 12:29 schrieb Harald Sitter: > > Servus, > > > > A while ago I prototyped a "new" approach to UI testing and I'm > > wondering if there's general interest in doing more Plasma testing > > using it. I'm able to invest time in polishing the experience for us. > > > > Very rough prototype: > https://invent.kde.org/sitter/selenium-webdriver-at-spi > > > > The testing is run through the accessibility API we have on Linux > > https://www.freedesktop.org/wiki/Accessibility/AT-SPI2/ as well as the > > testing API selenium https://www.selenium.dev/ respectively the more > > specific appium https://appium.io/ > > > > Architecturally appium is an extension to selenium and selenium is a > > client-server system where the client is the test and the server is a > > so called webdriver. Webdriver is a standardized well-defined API of > > various UI interactions https://www.w3.org/TR/webdriver/ and we'd > > implement one based on the a11y APIs (the feature sets match fairly > > well). > > > > Since selenium has wide spread use across the industry we get to use > > excellent tooling on the client without any extra work from us. And > > because it is so wide spread the stuff is generally very well > > maintained. All we need to maintain is the webdriver that interacts > > with the a11y API. > > > > The way this type of testing works is by UI interaction and state > > validation. There is a kcalc test available in the prototype repo [1] > > - the test operates the various UI elements to perform a calculation > > and then checks that the output UI element contains the expected > > value. > > > > A simple plasma test might open kickoff, and launch one of the > > favorites, then validate that indeed a new window has opened. > > > > Since all this is driven by the a11y API there is the additional > > advantage of making us notice a11y problems and deal with them, > > resulting in bettery a11y support in the long run. Two birds, one > > stone! > > > > What do you reckon? > > > > [1] > https://invent.kde.org/sitter/selenium-webdriver-at-spi/-/blob/91486b50995ade23c6b03a54f77347c263c2f03a/calculatortest.py > > > > HS > > +energy-efficie...@kde.org > > Servus Harald, > > that looks very cool! > > It could also come in handy for energy consumption measurements where we > need an automated and predictable way to emulate user interaction. > > The idea of using a11y API for that came up, but AFAIK there's no work > to actually do it on our side. > > That's three birds one stone I guess? > > Cheers > > Nico > > > PS: I pondered about different ways to do GUI automation for energy > consumption measurements in my master thesis recently, but I left the > a11y way for future work. If you are interested you can find the thesis > at https://nx9294.your-storageshare.de/s/PDQK4DEyPMW8AHM > > > > >
