Sap Fiori Opa5 Test Development

SAP Fiori OPA5 Development Skill

A guide for writing, fixing, and extending OPA5 integration tests for SAP Fiori Elements applications. Covers both OData V4 (sap.fe.test) and OData V2 (fioriElementsTestLibrary).

Not applicable to freestyle UI5 applications - for those, suggest the ui5-best-practices-opa5 skill from the UI5 Plugins for Coding Agents ui5.

Prerequisites

This skill requires an existing SAP Fiori Elements application generated by SAP Fiori tools with a test folder present (e.g. at webapp/test). If it is missing, follow the version-specific guide after detecting the OData version.

Step 1: Locate the Project Root

When the user provides a project name or ID (e.g. fin.test.rap.lr3) instead of a file path:

1. Search for manifest.json files under common project roots (e.g. webapp/manifest.json).
2. Match the "id" field in sap.app to the given name, or look for a folder whose name contains the given ID.
3. Once found, treat the folder containing webapp/manifest.json as the project root for all subsequent steps.

Step 2: Detect OData Version

Before writing any test code, determine whether the app is OData V4 or V2. The two test libraries are completely different and must never be mixed.

Primary check: manifest.json

Fallback check: metadata.xml

If manifest.json is inconclusive, check the <edmx:Edmx> root element in the service metadata file (typically at webapp/localService/mainService/metadata.xml, or wherever metadataPath points in ui5-mock.yaml):

These attributes appear on line 1 or 2 of the file.

If neither signal is present, ask the user to confirm the OData version before proceeding.

Step 3: Follow the Matching Guide

Once the version is confirmed:

1. Read the shared sections further below ("Test Endpoint and Running Tests", "Mock Server") - they apply to both V4 and V2.
2. Then read the version-specific guide for all test library decisions:

• OData V4 - read references/v4-instructions.md
• OData V2 - read references/v2-instructions.md

Adding a New Journey

When the user asks to add an additional journey (not just a new opaTest inside an existing journey):

1. Find the test root - search for files matching *Journey.js, *Journey.ts, *Journey.gen.js, or *Journey.gen.ts in the project. The folder containing those files is the integration test root. These files typically live in a folder named integration within the test directory, e.g. webapp/test/integration.
2. Understand the wiring - read the existing journey files and any entry point files to understand how journeys are registered. Three setups are possible:

• Virtual endpoint (V4) - no registration needed; the middleware picks up any file matching the configured pattern (default: ends in Journey.js or Journey.ts)
• Physical entry point (V4) - add the new journey's module path to the sap.ui.require array in OpaTests.qunit.js
• Custom wiring (e.g. S/4 apps with AllJourneys.js or AllJourneys.json) - follow the existing pattern

1. Create the journey file following the same naming pattern as existing journeys.
2. Confirm to the user which file was created and how it is registered (or that registration is automatic).

General Anti-Patterns (V4 and V2)

These apply regardless of OData version or test library.

Never invent method names. Only use methods that are confirmed to exist in the test library. If a method is not shown in the quick-reference patterns, do NOT guess or construct a name - look it up first:

• V4: check references/v4-standard-patterns.md for common patterns. If the method is not there, check references/v4-custom-selectors.md for custom selector patterns. If still not found, read references/v4-sap-fe-test-api-guide.md and consult the official sap.fe.test API documentation it points to. A method that "sounds right" is not sufficient — it must be confirmed to exist.
• V2: check references/fiori-elements-v2-test-library.md which contains the full API reference for all V2 page objects.

Invented methods fail silently with a "not a function" runtime error that is hard to diagnose.

Every `opaTest` must have at least one `Then` assertion. A test with only Given/When steps reports 0 assertions and fails silently.

// ❌ No Then = no assertions, test fails
opaTest("Click button", function(Given, When, Then) {
    When.onThePage.iClickButton();
});

// ✅ Always end with at least one Then
opaTest("Click button", function(Given, When, Then) {
    When.onThePage.iClickButton();
    Then.onThePage.iSeeThisPage();
});

OData property names are case-sensitive - always match the exact casing from metadata.xml. Wrong casing causes a timeout, not an error message.

OPA5 state carries over between `opaTest` blocks within a journey. Tests run sequentially and share the same browser session - do not assume the app is in a clean state at the start of each opaTest. Always navigate and assert explicitly rather than relying on state left by the previous test block.

The `pages` map key in JourneyRunner (V4) must exactly match the accessor name used in journeys. A mismatch causes a silent runtime error - the page object is simply undefined when the journey tries to call it. (V2 registers page objects globally via module loading and has no pages map.)

// ❌ Wrong - key is "onTheList" but journey calls "onTheListReport"
pages: { onTheList: ListReportPage }
// journey: When.onTheListReport.onTable()... → undefined

// ✅ Fixed - key matches accessor name exactly
pages: { onTheListReport: ListReportPage }

Keep journeys focused - split at around 10 `opaTest` blocks. Large journey files are slow to debug and hard to maintain. One journey file per feature or user flow is a good rule of thumb. Do not add tests for standard Fiori Elements behavior already covered by the test library itself.

Teardown method name differs by version. Always call teardown on Given, never on a page object:

• V4: Given.iTearDownMyApp() (capital D - overridden in sap.fe.test.BaseArrangements)
• V2: Given.iTeardownMyApp() (lowercase d - base Opa5 method)

QUnit requires assertions to validate tests. Teardown is not an assertion - always assert something before tearing down.

❌ Incorrect - teardown with no prior assertion:

// V4
opaTest("Should clean up", function(Given, When, Then) {
    Given.iTearDownMyApp();
});
// V2
opaTest("Should clean up", function(Given, When, Then) {
    Given.iTeardownMyApp();
});

❌ Incorrect - teardown chained on a page object instead of Given:

// V4
opaTest("Should assert state and clean up", function(Given, When, Then) {
    Then.onTheListPage.iSeeThisPage()
        .and.onTheListPage.iTearDownMyApp();
});

✅ Correct:

// V4
opaTest("Should assert state and clean up", function(Given, When, Then) {
    Then.onTheListPage.iSeeThisPage();  // assertion first
    Given.iTearDownMyApp();             // teardown on Given, separate step
});
// V2
opaTest("Should assert state and clean up", function(Given, When, Then) {
    Then.onTheGenericListReport.theResultListIsVisible(); // assertion first
    Given.iTeardownMyApp();                               // teardown on Given, separate step
});

Test Endpoint and Running Tests

These apply to both V4 and V2 projects.