Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Designing for testability

11 min

Listen to this lesson

0:00 / 7:34

The cheapest automation repair is the one that never has to happen. For SAP-delivered apps you take the UI as it is. For your own custom Fiori apps, you can ask for testability up front, and a short agreement with the developers saves weeks of maintenance per year. This lesson covers what to agree, how to check it, and how to write scripts that survive theme and layout changes in apps you do not control.

The stable ID agreement

SAP's own ID handling guide strongly recommends stable IDs wherever possible, because SAPUI5 flexibility (adaptation and variants), automated tests and inline help tools all depend on them. It goes further: stable IDs are part of the app's public API and must stay stable over its life cycle, and a control with a stable ID should not be deleted; if it must disappear, set it invisible instead. That is the contract you want in writing for every custom app.

  • Every interactive control (buttons, inputs, selects, tables, links, tabs) gets a stable, semantic ID in the XML view, for example approveButton or returnsTable.
  • Views created by routing get IDs in the manifest; views created in code use the owner component's createId.
  • IDs are named for meaning, not position, and do not contain hyphens, which the framework uses as separators.
  • Renaming or removing an ID is a breaking change: it is announced in the change, and the automation owner reviews it.
  • Dynamically created controls (dialogs, fragments, table rows) use view or fragment prefixes so IDs remain unique and predictable.
Under the testability contract, a stable ID changes only through a reviewed, announced breaking change.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Checking IDs before they reach you

Do not wait for a failing script to discover missing IDs. The UI5 Support Assistant, activated from the Technical Information dialog (Ctrl+Shift+Alt+P), has a rule named Stable control IDs are required for SAPUI5 flexibility services. SAP's guide walks through filtering the rules for "stable", selecting that rule and choosing Analyze; any controls with generated IDs are listed. Make that check part of the definition of done for every custom app story, and run it again in CMQ before automation starts.

The Support Assistant finds generated IDs before automation does, so they are fixed in the same sprint.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-202
  1. DesignAgree the testability contractStable IDs, test hooks and mock data are acceptance criteria on the story.
  2. BuildDeveloper testsQUnit and OPA5 tests run in the app repository with the mock server.
  3. Code reviewSupport Assistant checkNo generated IDs on interactive controls; ID changes flagged.
  4. CMQAutomation buildEnd-to-end scripts use the agreed IDs with their view names.
  5. Each releaseContract reviewRenamed or removed IDs reviewed by the automation owner before transport.
Where testability is agreed and checked in Contoso's custom app life cycle.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-202

Test hooks beyond IDs

  • Deterministic data: a way to create or reset the data a test needs, usually through the app's OData service or a released API, so UI tests do not depend on leftovers.
  • Clear messages: success and error messages that name the object and outcome, so assertions check meaning, not just that a toast appeared.
  • Observable completion: busy indicators that are reliably set and cleared, so synchronization works.
  • No hidden time dependencies: avoid logic that behaves differently near midnight or month end unless the date can be controlled in tests.

Tolerating theme and layout change

For SAP-delivered apps, the risk is not IDs but presentation. Themes change: recent releases moved users toward the SAP Horizon theme family, and administrators can change the default theme for everyone (check the default for your release and launchpad configuration). Layouts change: responsive tables pop columns into a second line on narrow windows, toolbars move buttons into an overflow menu, and Fiori elements apps gain or lose fields when annotations change. Scripts that survive this follow a few rules.

Fragile and shallowXPath to the third cell, asserts that a green icon is visible.
Stable but shallowControl selector finds the status, asserts only that it is not empty.
Meaningful but fragilePixel or CSS locator, asserts the correct order value.
RobustControl selector by binding path or ID, asserts status Approved and net value 12,000.00 USD.
Aim for the top-right quadrant: presentation-independent locators and business-meaningful assertions. The 12,000.00 USD net value is illustrative and assumes 50 CMC-ALT-100 at a 240.00 USD price.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-202
  • Assert on control properties and bound values, never on colors, icons, pixel positions or CSS classes.
  • Fix the browser window size for a run, and include the narrow layout only in tests that are about responsiveness.
  • Handle overflow menus in the page object: if a button is not in the toolbar, open the overflow and find it there, once, in one place.
  • Pin a theme for regression runs and test the theme change itself as a separate, deliberate check.
  • After every upgrade, re-run the Test Recorder over the key screens of SAP-delivered apps to confirm selectors still match uniquely.

What would you do?

A new version of a SAP-delivered list report adds two filter fields and moves the Export button into the toolbar overflow on smaller screens. Twelve Contoso scripts fail. Which approach prevents a repeat?

Key points
  • Stable IDs are part of a custom app's public API: set them, name them semantically, never delete them silently.
  • Check with the Support Assistant's stable-ID rule before automation starts, and on every change.
  • Ask for test hooks too: deterministic data, clear messages, reliable busy states.
  • For SAP-delivered apps, use presentation-independent locators and assert on business meaning.
  • Pin window size and theme for regression; test theme and responsiveness deliberately and separately.

Check your understanding · not graded

Lesson check

  1. 1. According to SAP's ID handling guide, what should a developer do instead of deleting a control that has a stable ID?

  2. 2. Which tool can list controls that lack stable IDs in a running UI5 app?

  3. 3. Which assertion best tolerates a theme change?

  4. 4. Why should stable IDs avoid hyphens?