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
