UI5 testing
Proving a UI still works — unit tests over controllers and formatters, integration tests that drive real controls, and end-to-end runs against a served app.
Showing artifacts, examples and content with confirmed Freestyle applicability. View All UI5
Overview
The framework's own stack, aimed at code the developer wrote: QUnit over the controllers, formatters and modules of the app, OPA5 over the controls in its views, and the OData V2 mock server standing in for the service. SAP's testing tutorial walks all three.
Not covered: At the browser the pages were opened in. The framework ships no runner that executes the pages unattended — its testing page points at a local test runner for that — and OPA's restrictions hold: no screen capturing, no test across more than one page, no remote execution.
A command line that runs the project's existing QUnit and OPA5 pages across parallel browsers, a WebdriverIO service that drives a served app as a user would, Node.js test environments for unit tests, and recorders and generators that write the test code or the mock data the developer would otherwise type.
Artifacts
Tasks
Run a UI5 app's tests with no backend behind it
The application under test answers its own service calls from mock data, so the tests run with no backend reachable.
Covers standing in for the service. Writing the tests is a different task, and so is keeping mock data in step with a model that changes.
@openui5/sap.ui.coreThe OData V2 mock server intercepts the application's calls inside the client, with no network behind it, and answers from data generated out of the service metadata or from JSON files the project keeps.
Conditions: The service is OData V2: the page states the mock server included with SAPUI5 mimics OData V2 back-end calls, and that the OData V4 mock server functionality is included with CAP Node.js The resources are represented as JSON, which the page states is the only format the mock server supports
Remaining work: Decide between generated data and hand-kept JSON files, and keep the files in step with the metadata as the model changes.
Run a UI5 project's existing QUnit and OPA5 pages unattended
The test pages a project already has run from one command, with nobody opening them in a browser tab, and the run leaves a report a pipeline can read.
Covers executing pages that exist. Writing them is a different task, and so is what serves the application while they run.
@openui5/sap.ui.coreShips the QUnit and OPA5 the pages are written against, and the testsuite page that lists them. What it does not ship is the thing that opens them: its own testing page hands that job to a local test runner.
Conditions: A runner outside the framework executes the pages; the framework's testing page names a local test runner such as Selenium or Karma for that
Remaining work: Choose and configure that runner, and decide where its report goes.
Test a UI5 app that is already deployed, from a pipeline
A test reaches the application a user would open — deployed, served by somebody else, possibly behind a login — and the run happens in a pipeline rather than on a developer's machine.
Covers reaching and driving a deployed application. What the tests assert, and how the application got deployed, are not part of it.
wdio-ui5-serviceOpens the baseUrl its configuration names in a real browser, waits for the redirect to the authentication provider and supplies the credentials, with the provider chosen by configuration rather than written into the tests. Tests start through WebdriverIO's own command line, so a pipeline step is what runs them.
Conditions: The login is one the authentication page covers — SAP Cloud IdP, SAP Cloud Identity Services, Office 365, a custom provider or basic authentication — and does not require a second factor, which that page states is not supported
Remaining work: Put the credentials where the pipeline can hand them to the configuration, and keep the test code itself free of the login: the documentation states no changes in the test code are needed for using authentication.
@openui5/sap.ui.coreThe framework's integration tool is OPA5, and its page rules this scope out: remote test execution is listed among OPA's restrictions, as is testing across more than one page, and the page states end-to-end tests are not recommended with OPA because of authentication issues and fragile test data.
Remaining work: Nothing to configure here. The framework's own page sends this job outside OPA.
Details
Coverage
Comparison properties
These are the questions used to compare what the artifacts do. Values come from their documentation and may apply to a particular ecosystem or runtime. Each recorded value in the comparison opens its statement and sources.
For your agent
- Ref
capability:ui5-testing- JSON
- /capabilities/ui5-testing.json
- MCP
- Connecting an agent