wdi5 – release, state of things, outlook
wdi5 was announced as UIveri5-successor mid-February, the announcement also contained a roadmap and an outlook on what’s next for the tool.
SAP took the opportunity and sponsored the Open-Source development of
wdi5 to make sure the tool reaches feature parity with UIVeri5.
As the official release
0.9.0 just happened, let’s look at where we’re at.
TypeScript rewrite and drop
UIVeri5 element matchers and feature parity
There’s a PR for adding the
browser.asControl dialect to UI5’s test recorder currently in the works, so consider this done pretty soon.
☑️ done – published into the GitHub Container registry, as a combination of
wdi5-version and Node.js-version.
browserstack- and sourcelabs-integration
thanks to the standard integration with WebdriverIO,
wdi5 will mostly re-use its’ feature; work is under way.
work is under way, first extension will be a BTP login option for
to lower the entry barrier as much as possible, we’re still evaluating options; one of them being a Jupyter Notebook hookup to a preconfigured
wdi5 environment. But nothing definite here yet.
wdi5 generator for
in the works, will happen 🙂
support visual regression testing
same as for the “playground”, different options are still evaluated. No decision yet on what approach/extension/tool to take.
some non-roadmap highlights
UI5 Control API support, including object access
Once a UI5 control is retrieved via
await browser.asControl(selector), all API methods of that control can be executed on it.
const button = await browser.asControl(buttonSelector) const text = await button.getText() // this is getText() from https://ui5.sap.com/#/api/sap.m.Button%23methods/getText !
fluent async api
To allow more concise coding, an asynchronous Promise chain can be
awaited within a single instruction:
// same as above, but as an async Promise chain const text = await browser.asControl(buttonSelector).getText()
support UI5 web components
thanks to the standard integration with UI5’s test API, retrieving and operating a UI5 Web Component is little different from working with a regular UI5 control:
const webcomponent = await browser.asControl(webComponentSelector) await webcomponent.setValue("wdi5!")
The example uses the retrofit of the UI5 web components to offer “Control”-compliant APIs, such as the generic
setValue e.g. for input fields.
TDD with –watch
By passing the
--watch at test execution, the targeted browsers remains open and changed tests are rerun!
npm run yourWdi5Script – –watch
There will be more blog posts and other content on all of the above coming during the next weeks.
Fiori Elements “Testing Library” support
Still in the works, and will be described in more detail soon – there’s a generic “Testing Library” for operating standard User Interactions on Fiori Elements applications. So far, it is compatible with
OPA5 only, but integration into
wdi5 will happen as well, done by the fantastic @nlunets.
Yes, that’s right: simulating dragging and dropping a UI5 element.
An enhancement to WebdriverIO’s excellent “multiremote”-feature – think of it as operating more than 1 browser within the same test(s), for simulating multi-user interactions with a UI5 app; done by the fantastic @monavari-lebrecht.
All of the above features will come to
wdi5 from UI5 community members, not via a channeled company-driven development effort – from the UI5 community, for the UI5 community 💙🤗!
That’s just another reason for moving
wdi5 into the
ui5-community – yes, after the inital wave of SAP-sponsored development flattens out, the community-driven
wdi5 will also move digitally into the proper
ui5-community GitHub organization. More on that in a later blog post.
And last but not least: there will be a workshop on using
wdi5 at UI5con 2022! That’s where we’ll work together to “test all the things”™ in a curiosity-driven and friendly manner – see you there ✌️