Lesson 5 of 6
Test suites through the upgrade: OPA5 and wdi5
10 min
Listen to this lesson
A remediation is only as safe as the tests around it. Contoso's UI tests come in two kinds: OPA5 journeys that run inside the app in the browser (UI5's own integration test framework, covered in the Fiori automation course) and wdi5 tests that drive the app from outside through WebdriverIO with UI5-aware selectors. Both must survive the same changes as the app: async loading, removal of globals, the Test Starter. Ravi, the TCoE automation lead, owns both suites.
| Aspect | OPA5 | wdi5 |
|---|---|---|
| Runs | In the browser, inside the app's frame, with QUnit | Outside the app through WebdriverIO, controlling a real browser |
| Typical use | Developer integration tests, often with mock data | End-to-end tests against a real back end and launchpad |
| Finds controls by | Control type, ID, view name, properties, matchers | UI5 control selectors (control type, ID, view, properties) |
| Waits | Built-in waiting for UI5 to be idle | Waits for UI5 through the service before acting |
| Affected by 2.x rules | Test code using globals, QUnit 1, old test pages | Test code relying on DOM structure or global UI5 access |
Making OPA5 suites legacy-free
SAP's best-practices page has a testing section, and it applies to test code exactly as to app code. Ravi's checklist for each OPA5 suite:
- Move test pages to the Test Starter (a
testsuite.qunit.htmlwith atestsuite.qunit.jsconfiguration). The linter'sprefer-test-starterrule finds suites that do not. - Move from QUnit 1 to QUnit 2 and from old Sinon versions to the current one.
- Load page objects, journeys and test modules with
sap.ui.define; give each a unique module name. - Replace global access in tests (
sap.ui.getCore(),sap.ui.test.Opa5as a global) with required modules. - Check that spies and stubs still attach after deprecated APIs were replaced; a stub on a removed API silently stops intercepting.
- Replace Blanket.js coverage with IstanbulJS, as SAP recommends.
- Run
ui5linton the test folder too.
Fiori elements tests
For Fiori elements V4 apps, SAP provides an OPA-based test library in sap.fe.test with journey runners and ready-made page objects for list reports and object pages, and SAP Fiori tools can generate a starting test set when the app is created. Contoso extends the generated tests for its custom sections and actions. Because the framework owns the floorplan, these tests rarely break on framework changes; when they do, it is usually a custom extension that used internals.
wdi5 through the change
wdi5 is an open-source service for WebdriverIO from the UI5 community. Its tests find controls through UI5 selectors, for example a control of type sap.m.Button with a given ID in a given view, rather than through CSS or XPath, so they survive DOM changes when the framework renders differently. They break when IDs are generated rather than stable, when the test reaches into UI5 through globals, or when a test assumes a synchronous load and acts before the view exists. Ravi's rule: every control a wdi5 test touches has a stable ID set in the view or the manifest.
Stable IDs: the agreement between developers and testers
Both OPA5 and wdi5 work best with stable IDs. In XML views, give every control a test touches an id; in Fiori elements apps, use the IDs the framework derives from annotations and the stable IDs you set on extensions. Ravi and Kenji agreed a short naming rule (view prefix, purpose, control type) and a linter-style review check: a pull request that adds a control without an ID, where a test needs one, is sent back. That agreement is cheaper than any amount of selector maintenance later.
Running against what users will get
Tests must run on the SAPUI5 version the app will meet. For apps on the S/4HANA front-end server, that is the version shipped with Contoso's SAP S/4HANA 2025 release and its maintenance updates; for BTP apps, the version set in the app's bootstrap or the launchpad. While 2.x was in preparation, SAP suggested testing against its nightly 2.x build as an early warning; Contoso keeps one non-blocking pipeline job doing that for the BTP apps, treating failures as information, not as release blockers.
What goes wrong
- Deleting red journeys. A suite that shrinks every time the app changes protects nothing.
- Sleeps instead of waits. Fixed delays pass on fast machines and fail on slow ones; use the frameworks' idle waiting.
- Generated IDs. Tests break after every remediation because IDs like
__button12changed. - Testing on the wrong version. Green on the developer's local SAPUI5, red in CMQ.
What would you do?
After remediating ZCMC_FLEET_STATUS to async loading, three wdi5 tests fail intermittently in CMQ: sometimes the table is not found. The tests pass when rerun. What should Ravi change first?
- OPA5 runs inside the app with UI5's waiting; wdi5 drives a real browser with UI5 control selectors.
- Test code must be legacy-free too: Test Starter, QUnit 2, sap.ui.define, no globals.
- Stable IDs and UI5-aware waiting make suites survive async loading and DOM changes.
- Run tests on the SAPUI5 version the app will meet; use nightly builds only as early warning.
Check your understanding · not graded
Lesson check
1. Which linter rule flags suites that do not use the Test Starter?
2. How does wdi5 find UI5 controls?
3. What does SAP recommend instead of Blanket.js for coverage?
4. Which library offers OPA page objects for Fiori elements V4?
5. Why replace fixed sleeps in UI tests?