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.
Overview
@openui5/sap.ui.core The OpenUI5 core: the module loader, the MVC runtime, data binding, routing, theming and the test stack, which is everything a UI5 app does before a single community package is added.
Not covered: Inside the page the tests opened, and at the test pages themselves. OPA's own documentation lists screen capturing, testing across more than one page and remote test execution as restrictions, and states that end-to-end tests are not recommended with OPA because of authentication issues and fragile test data. The framework ships the test frameworks and the pages rather than anything that executes them unattended, and its mock server mimics OData V2: the same documentation states the OData V4 mock server functionality is included with CAP Node.js.
The door's answer to the end-to-end layer is wdi5wdio-ui5-serviceEnd-to-end testing for UI5 as a WebdriverIO service that drives a real browser through UI5's own test API, so a test addresses controls with OPA5-compatible selectors rather than DOM nodes.community org, ui5, a WebdriverIO service that drives a real browser against a served app with selectors compatible with OPA5's and supplies the credentials at the identity provider the configuration names; SAP's own testing page names it beside OPA5. Beside it the community answers what the framework leaves out: executing a project's existing QUnit and OPA5 pages unattended, as wdio-qunit-servicewdio-qunit-serviceA WebdriverIO service that runs QUnit HTML test pages in a browser and reports the results as WebdriverIO test suites, presented as a drop-in replacement for Karma-based QUnit setups.independent, ui5 does in place of Karma, running unit tests in Node.js under Jestjest-environment-ui5A Jest test environment named ui5 that boots UI5 from a local HTML file into jsdom, so UI5 unit tests run in Node.js with no web server and no browser.independent, ui5 or Vitestvitest-environment-ui5A Vitest environment named ui5 that boots UI5 from a local HTML file into jsdom, so UI5 unit tests run in Node.js with no web server and no browser.independent, ui5 with no browser, generating mock data with Faker.jsopenui5-smart-mockserverAn extended UI5 MockServer that generates meaningful mock data with Faker.js, from the metadata's sap:semantics annotations or from rules that map an OData property to a Faker method.independent, ui5 instead of typing it, and recording a journey or live OData traffic instead of writing the test code and the mock data by hand. SAP's ui5-middleware-code-coverage@ui5/middleware-code-coverageUI5 CLI server middleware that instruments a project's JavaScript files with Istanbul as the dev server sends them, and generates the coverage report from the records the OpenUI5 QUnit tests send back.sap official, ui5 reports coverage for the QUnit tests of a project served by the UI5 CLI.
Artifacts
Tasks
Get test code for a Fiori elements screen without writing selectors by hand
A test addresses the controls of a generated list report or object page without a developer working out locators for ids the framework generated.
Covers getting to the code or the locator. What the test then asserts, and running it, are other tasks.
ui5-journey-recorderA Chrome extension that records the clicks and inputs made against a running application and exports the recording as OPA5 or wdi5 code, so the sequence comes out of the recording along with the locators.
Remaining work: Install the extension in Chrome, record against a running application, and keep the exported code as the project's own.
wdi5-fe-selectorsAnswers the same outcome without recording anything: a set of wdi5 selectors for the controls Fiori elements generates, so a hand-written test takes the locator from the set instead of deriving it from a generated id.
Remaining work: Install it beside wdi5 and use its selectors in the tests you write; it supplies locators and not the journey.
@openui5/sap.ui.coreThe framework's own Test Recorder answers this — its page states the tool is part of the SAPUI5 framework, that it hands back a snippet for a control on the page, and that the raw dialect gives just the locator for use in other frameworks. Which published package a project gets it from is not established for this entry: the OpenUI5 repository ships it as a library of its own, sap.ui.testrecorder, beside sap.ui.core rather than inside it, and the graph holds no entry for that library.
Remaining work: Establish which package carries the Test Recorder before this is recorded as a contribution of @openui5/sap.ui.core, and consider an entry for the library itself.
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.
ui5-middleware-odata-recorderSupplies the data from the other direction: a server middleware records the OData traffic a running application makes and writes entity JSON files and metadata.xml, so the replay answers with what a real backend returned rather than with records written by hand.
Conditions: The project replays with the SAP Fiori elements mock server, which is what the recorder generates its files for The recorded journey touched the entities the tests need: the dataset holds what the application asked for and nothing else
Remaining work: Record a journey that touches everything the tests touch, turn the Fiori tools app reload off while recording, as its README asks, and set up the mock server the files are written for.
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.
ui5-test-runnerOne command runs the project's QUnit and OPA5 pages, each page in its own browser instance and a configurable number at a time, two by default, and consolidates every result into one report. Nothing in the existing test files changes.
Remaining work: Pick the mode: remote mode takes the URL of a test suite page on an application somebody else serves, legacy mode has the runner serve the application itself. Coverage is a switch in version 6 rather than the default.
@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.
karma-ui5-transpileMakes the Karma way work for a project whose sources are TypeScript: the preprocessor transpiles them with the project's own ui5-tooling-transpile configuration before the tests run, which is how coverage is collected for such a project. Its README states the project has been deprecated and points at the UI5 community projects tagged testing.
Conditions: The project has a ui5.yaml configuring ui5-tooling-transpile 3.0.0 or later, and karma 6.4.1 or later The karma-ui5 plugin is installed alongside it, which the README calls obligatory because the configuration is read from it
Remaining work: Install karma, karma-ui5, karma-coverage and a browser launcher beside it, configure the preprocessor per path in karma.conf.js, and keep the coverage preprocessor out of that list, which the README warns would instrument the sources twice. Picking a successor is the maintainer's own advice.
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.
ui5-test-runnerReaches a deployed instance from the other side: remote mode takes the URL of the application's test suite page and needs no access to the sources, so what runs is the in-page suite on a deployed application rather than a journey through it.
Conditions: The application's test suite page is reachable at a URL, which is where remote mode starts
Remaining work: Deploy the test pages with the application, point the runner at their URL, and establish how the run gets past a login — nothing read for this assessment states that it can.
@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.
Content
Seen working
Neither the package manifest nor the repository tree declares a licence.
Neither the package manifest nor the repository tree declares a licence.
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