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