SAPUI5 and Fiori Tools Part 6: Debugging, Testing and Performance
Find and fix problems in SAPUI5 apps: identify the failing layer, use browser developer tools and UI5 diagnostics, write QUnit and OPA5 tests, and apply the most important performance measures.
Explanation
📌 KEY POINTS
✅ First find the layer: UI (view/controller), model/binding, network/OData, or backend (RAP).
✅ Tools: browser DevTools (Console, Network, Sources), UI5 Diagnostics (Ctrl+Alt+Shift+S), UI5 Inspector, Support Assistant (Ctrl+Alt+Shift+P).
✅ Tests: QUnit for logic (formatters, controllers), OPA5 for user journeys.
💡 Performance: async loading, component preload, $select via autoExpandSelect, no synchronous calls.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–5 built the app. This part keeps it working and fast.
━━━━━━━━━━━━━━━━━━━━
▶ 1. DIAGNOSE THE CORRECT LAYER
For a failing screen, ask in order:
- Console errors? (JavaScript error, missing module, binding syntax) → UI layer.
- Network: which OData request failed, with which status and error body? → OData/backend (see OData V4 Part 5).
- Request OK but UI wrong? → binding path, model name, formatter, control properties.
- Data wrong in the response? → backend (CDS, RAP) — switch to ADT.
━━━━━━━━━━━━━━━━━━━━
▶ 2. BROWSER DEVTOOLS
- Console — errors and warnings; sap.ui.getCore().byId("…") to inspect controls (in debug mode).
- Network — filter "$batch"; open the batch payload to see individual requests and responses.
- Sources — breakpoints in controllers; enable debug sources with URL parameter sap-ui-debug=true.
━━━━━━━━━━━━━━━━━━━━
▶ 3. UI5 TOOLS
- Diagnostics window (Ctrl+Alt+Shift+S): UI5 version, loaded libraries, control tree, debug sources, technical info.
- UI5 Inspector (browser extension): control tree, properties, bindings, models per control.
- Support Assistant (Ctrl+Alt+Shift+P): rule-based check for common issues (performance, accessibility, deprecated APIs).
- URL parameters: sap-ui-debug=true, sap-ui-logLevel=debug (versions vary), sap-ui-language=EN.
━━━━━━━━━━━━━━━━━━━━
▶ 4. TESTING
- QUnit — unit tests for formatters, utility modules and controller logic; fast, run in the browser or CI (e.g. with Karma or UI5 test runner).
- OPA5 — integration tests simulating user journeys (open list, press item, check detail) with mock data.
- Mock server — run the app and OPA tests with local mock data (Fiori tools can generate a mock server config from $metadata).
- Fiori tools generators create test skeletons; keep them green in CI.
━━━━━━━━━━━━━━━━━━━━
▶ 5. PERFORMANCE
- Load asynchronously: "async": true in manifest and bootstrap (data-sap-ui-async="true").
- Component preload (build creates Component-preload.js) — fewer requests.
- Request only needed data: autoExpandSelect, $top paging (growing tables), no to-many $expand in lists.
- Avoid synchronous XHR and heavy formatters in large tables.
- Lazy-load fragments and dialogs.
- Check with the browser Performance tab and Lighthouse.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Break a binding path on purpose and find it with UI5 Inspector.
- Force a backend validation error and read it in the Network tab.
- Add one QUnit test for a formatter and one OPA5 journey.
- Run the Support Assistant and fix the top three findings.
✅ CHECKPOINT: you can locate UI problems quickly and protect the app with tests.
Code example
// ===== Debugging quick reference =====// URL parameters (append to app URL):// ?sap-ui-debug=true -> non-minified sources for breakpoints// &sap-ui-language=EN -> reproduce with a defined language// Keyboard:// Ctrl+Alt+Shift+S -> UI5 Diagnostics (version, control tree, debug sources)// Ctrl+Alt+Shift+P -> Support Assistant (rule checks)// DevTools Network: filter "$batch" -> open payload -> find failing request + error body // ===== QUnit: test a formatter (test/unit/model/formatter.js) =====sap.ui.define(["zpurchreq/model/formatter"], function (formatter) { "use strict"; QUnit.module("statusText"); QUnit.test("maps status codes to texts", function (assert) { assert.strictEqual(formatter.statusText("N"), "New"); assert.strictEqual(formatter.statusText("S"), "Submitted"); assert.strictEqual(formatter.statusText("A"), "Approved"); assert.strictEqual(formatter.statusText("X"), "X", "unknown code returned unchanged"); });}); // ===== OPA5: user journey (test/integration/NavigationJourney.js) =====sap.ui.define(["sap/ui/test/opaQunit", "./pages/List", "./pages/Detail"], function (opaTest) { "use strict"; QUnit.module("Navigation"); opaTest("Open a request from the list", function (Given, When, Then) { Given.iStartMyApp(); // with mock server data When.onTheListPage.iPressOnTheFirstRequest(); Then.onTheDetailPage.iShouldSeeTheRequestTitle(); Then.iTeardownMyApp(); });}); // ===== Performance checklist (manifest / index) =====// "sap.ui5": { "dependencies": { "minUI5Version": "..." }, ... }// bootstrap: data-sap-ui-async="true" manifest models: autoExpandSelect: true// build: ui5 build (Component-preload.js) tables: growing="true" growingThreshold="20"Real project scenario
Users complained that the purchase request list took eight seconds to load. The developer suspected the backend. In the Network tab, the $batch showed one request with $expand=_Item for 200 requests and all fields — generated by a table binding with an item count column bound through _Item.
Replacing the column with an aggregated ItemCount field from CDS, enabling autoExpandSelect and a growing table with 20 rows reduced load time to under one second. The team added an OPA5 test for the list journey and a Support Assistant run to their release checklist.
Common mistakes
- Debugging the backend before checking the browser Network tab.
- Using minified sources for breakpoints.
- No automated tests, only manual clicking.
- Expanding to-many navigation in list bindings.
- Synchronous loading and missing component preload.
- Heavy formatters in large tables.
Best practices
- Locate the layer first: console → network → binding → backend.
- Use UI5 Diagnostics, Inspector and Support Assistant routinely.
- Cover formatters and logic with QUnit, key journeys with OPA5 and mock data.
- Load async, build preload bundles, request only needed data.
- Measure performance before and after changes.
Interview angle
Questions: "How do you debug a SAPUI5 app?", "QUnit vs OPA5?", "How do you improve UI5 performance?"
Strong answer: identify the layer using console, Network ($batch payloads and error bodies), UI5 Inspector for bindings, Diagnostics (Ctrl+Alt+Shift+S) and sap-ui-debug; QUnit tests units like formatters, OPA5 tests user journeys with a mock server; performance via async loading, component preload, autoExpandSelect/$select, growing tables, avoiding to-many $expand and synchronous calls; Support Assistant for rule checks.
Practice this lesson
Quick check
1. Which tool shows the control tree and bindings of a running UI5 app?
2. What is OPA5 used for?
3. Which list binding pattern is most likely to make a table slow?
Interview questions
1. How do you debug and test SAPUI5 applications?
Answer it in your own words first, then compare.
2. A purchase request list takes eight seconds to load. How do you analyze and fix it?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- SAPUI5 and Fiori Tools Part 1: MVC, Models, Views and Controllers
- SAPUI5 and Fiori Tools Part 2: Set Up BAS or VS Code and Generate an App
- SAPUI5 and Fiori Tools Part 3: Data Binding — JSON Model, OData Model, Modes
- SAPUI5 and Fiori Tools Part 4: Routing, Navigation, Fragments and Dialogs
- SAPUI5 and Fiori Tools Part 5: OData V4 Read, Create, Update and Errors
- SAPUI5 and Fiori Tools Part 7: Deployment to BTP and ABAP