testing UIs and improving a11y all at once!

[Alexey Andreyev]

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.fella at 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-efficiency at 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-eco-discuss/attachments/20220810/22d4fd8a/attachment.htm>