UI5's built-in test tools

SAPUI5 comes with its own testing toolkit, and it is aimed squarely at developers. Testers who understand it can do two valuable things: push checks down to where they are cheap, and avoid duplicating in slow end-to-end scripts what the developers already prove in seconds. SAP's testing documentation for UI5 recommends QUnit for unit tests, OPA5 for integration tests, a mock server to run the UI without a live back end, and a separate end-to-end layer that drives a real browser against a real system.

QUnit: unit tests for UI5 code

QUnit is an open-source JavaScript unit-testing framework that UI5 uses for its own tests and recommends to app developers. A QUnit test exercises one module: a formatter that turns a status code into text, a function that computes a total, a controller method that decides whether a button is enabled. No back end and often no rendering is needed. In SAP's testing tutorial, unit tests live in webapp/test/unit, integration tests in webapp/test/integration, and a test suite file lists them all so they run together. UI5's test starter concept reduces the boilerplate, loads the common test frameworks and lets the test configuration live outside the test code.

OPA5: integration tests through the UI

OPA5 (One Page Acceptance tests) is an API for UI5 controls that ships with UI5 and is built on QUnit. SAP describes it as hiding asynchronicity and easing access to UI5 elements, which makes it well suited to testing user interactions, navigation and data binding. A typical OPA5 test reads like a story in arrange-act-assert form: Given I start the app, When I press the Create button, Then I see the new item. Tests are grouped into journeys and use page objects, so each view's actions and assertions are written once and reused.

Under the hood every step is a waitFor: OPA5 polls until a control matching the given ID, view name, control type and matchers exists and is in the right state, then runs an action such as Press or EnterText. Because it polls instead of sleeping, it is fast and tolerant of loading delays. SAP lists its limits honestly: OPA5 runs inside the app's own browser window, does not cover several pages or remote execution, takes no screenshots, and SAP does not recommend it for end-to-end tests because of authentication and fragile test data. That is why it sits at the integration layer and not at the top.

Mock server and Fiori elements test library

The UI5 mock server mimics an OData service from its metadata and JSON mock data, with a configurable delay so the app behaves as if a real service were answering. Developers can test the UI before the back end is ready, and tests become repeatable because the data never drifts. For SAP Fiori elements apps on OData V4, SAP also provides an OPA test library with reusable functions for common steps such as starting the app, loading data and navigating, so developers only write the app-specific parts.

The Test Recorder

Since UI5 1.74 the Test Recorder is part of the framework, so it is available in any UI5 app on that version or later, including apps in your quality system. Open it with Ctrl+Shift+Alt+T (or from the Technical Information dialog, Ctrl+Shift+Alt+P). It shows the control tree, each control's properties and bindings, and generates snippets: a raw control selector, or an OPA5 statement, for highlight, press and enter-text actions. Since 1.88 it can also generate assertions on property values. For an automation engineer, it is the quickest way to see whether a control has a stable ID and which selector would find it uniquely.