What's cooking in the wdi5 kitchen

[vobu]

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 👨‍🍳 😉

[joe_valliparampil2]

hello vobu ,

After generating wdi5 code using UI5 Journey Recorder, we noticed the code generated for a very small SAPUI5 Freestyle app was missing details for the navigation path and had small mistakes related to syntax. The code generated for Fiori elements worked as expected.

Is the UI5 Journey Recorder intended to work only with Fiori elements? Is this question only relevant for the UI5 Journey Recorder and not related to wdi5? I am also raising this as an issue in GitHub UI5 Journey Recorder repo.

Thank You,

Joe Valliparampil.

[vobu]

Hi, I saw that you already posted this in the proper place over at the journeyrecorder repo - so things will continue there, I hope.

[crashmydev]

Hi vobu,

any news on the CAP localhost basic Auth flow?

Is there any known workaround in the meantime? We would really love to use it in our product.

 

Thank you and kind regards,

Tim Hollinger

[vobu]

puppeteer and devtools support is done, Testing at scale, autoWaiter enhancements + WorkZone are about to be completed.

But no real visible progress on v8 and the CAP localhost flow, I'm afraid...purely due to time constraints though. Would you mind giving it a shot? I think scoen already has some ideas - would be great if you could align a crunch something out 😊