Even though we have a stable wdi5 major version 1, there’s still plenty left to do. And since you have continued adopting (thanks!) and even contributing (major THANKS!) to wdi5, here’s an overview what we’re currently working on:
wdio v8 enablement
We wanted to allow Webdriver.IO (wdio) to stabilize somewhat after its’ major version bump. Now is the time to upgrade our wdio service, namely wdio-ui5-service (the technical module name of wdi5!) to wdio v8 APIs. This will allow using wdi5 both as an ESM module (import { wdi5 } from "wdio-ui5-service") and a CJS module (const { wdi5 } = require("wdio-ui5-service")) at dev time. And of course greatest precaution is put on getting the alignment to v8 done without introducing breaking changes to wdi5 itself.
enhanced autowaiter
wdi5 (re)uses UI5’s sap.ui.test.autoWaiter API to sync with the lifecycle of a UI5 app. Because of this close API alignment with both UI5 and OPA5 and rising adoption amongst you (thanks again, folks!!!), some missing functionality surfaced in the autowaiter API. Once reported to the UI5 core team, they stepped in immediately and are already working on enhancing the autowaiter – this is what Open Source community and vendor cooperation looks like 💙.
“SAP Workzone, standard edition” enablement
What was formerly known as the Launchpad is now “Workzone, standard edition”. When your UI5 app runs as part of the standard Workzone edition, an iframe is used to run it in the Workzone “shell” context. For wdi5 to be able to reach that iframe, we’ll unpack a bag of technical tricks to make that happen 🪄🔨, specifically in combination with authentication.
testing at scale
There are still edge cases with certain tests in some browser/OS combinations that we‘d like to iron out. For this, we‘ll utilize the Cloud Testing packages both Saucelabs and Browserstack have graciously sponsored us with. The setup for this testing at scale will benefit most of you as well as it can serve as a blueprint for your project to run wdi5 tests cross-OS/-browser without having to expand your infrastructure.
puppeteer and devtools support
Webdriver.IO has a fallback that allows running tests with the [devtools-](https://chromedevtools.github.io/devtools-protocol/) instead of the [WebDriver-protocol](https://www.w3.org/TR/webdriver/). This “backup” also applies to wdi5 in return. Plus devtools is also used when wdio/wdi5 is run without any browser driver is specified, which will utilize puppeteer as the user agent. Plain and simple: devtools/puppeteer doesn’t work properly in wdi5 yet. But that bug is hunted down as we write/read here 😄
CAP localhost auth support of model permissions
When your UI5 app is part of a locally run CAP project, and some services are annotated requiring authentication, CAP will use Basic Auth for that at dev time. Due to the sequence of http calls being done under the hood between UI- and Service-Layer, CAP’s Basic Auth prompt escapes [wdi5‘s authentication mechanism](https://ui5-community.github.io/wdi5/#/authentication). We’re looking into options on how to best support that dev time setup in wdi5 as well.
So it’s obviously busy in the wdi5 kitchen 👨🍳!
What’s specifically worth mentioning is that a growing number of community members started contributing code to wdi5 over the last couple of weeks. Because wdi5 is first and foremost an Open Source project that can only continue to thrive when all of you users keep on bringing in bug reports and fixes, feature implementations and documentation improvements 💪
That being said: for the German speaking community, there’s a wdi5 hybrid training coming up on March 8th, organized by the DSAG – on-site is fully interactive, remote is “listen-in” only. For you all, that’s not only an opportunity to level up your testing skills both for development and Continuous Integration; but also a chance to discuss upcoming features and onboard for developing wdi5 itself, thus becoming a part of the wdi5 chef de cuisine crew 👨🍳 😉
