Lesson 5 of 5
Testing each pattern
10 min
Listen to this lesson
Side-by-side extensions are often tested like a single app: someone opens the UI in test, clicks around and signs off. That misses most of what can go wrong. An extension is a small distributed system: its own code, the SAP S/4HANA interfaces it relies on, the platform configuration in each subaccount, and the people and events that drive it. Priya's test strategy for Contoso's extensions gives each of those its own kind of test.
Contract, integration and end-to-end
A contract test checks the interface, not the business flow: do the entity sets, fields, types and keys the extension uses still exist in the API as deployed in CMQ, and does the event payload still contain the key the subscriber reads? Run them when SAP S/4HANA is upgraded or a support package is applied, and when the extension changes which fields it uses. An integration test runs the deployed extension in cmc-ext-test against real services, proving destinations, tunnels, trust and roles. An end-to-end test follows a business flow, for example Maria changing a fleet order in CMQ and the fleet desk seeing the inquiry update, and is the evidence key users sign off on.
| Pattern | Must-have tests | Typical evidence |
|---|---|---|
| UI extension | Service tests with mocked APIs; contract tests for each consumed API; UI tests of key screens; E2E for main user journeys | Test run results, API version list, screenshots of E2E steps |
| Process and workflow | One test per decision branch and deadline; write-back to SAP S/4HANA; substitutes and rejected paths | Process instance logs, resulting SAP document numbers |
| Event-driven | Event received and handled; same event twice (idempotency); events out of order; broker or subscriber down and recovered | Broker and app logs, final state compared with SAP S/4HANA |
| Data extension | Reconciliation of totals and counts with SAP S/4HANA; refresh timing; authorization on data | Reconciliation sheet signed by the process owner |
Minimum test content per pattern.
Events need unhappy-path tests
Event-driven extensions fail in ways a UI test will never show. Brokers may deliver an event more than once, so handlers must be idempotent: processing the same event twice must not create two inquiries. Events can arrive late or out of order, so a handler that reads the current state through the API, rather than trusting the event's order, is more robust. And when the subscriber is down, messages wait in the queue; the test should prove that they are processed once it is back, and that operations is alerted if the queue grows.
- Every changeComponent and service testsRun in the build pipeline with mocked SAP S/4HANA APIs and events
- Every deployment to testIntegration smoke testsDestinations, identity and broker in cmc-ext-test against CMQ client 100
- SAP S/4HANA upgrade or support packageContract testsConsumed APIs and events checked against the updated CMQ before CMP is touched
- Release candidateEnd-to-end and UATBusiness flows across both platforms with key users
- After go-liveMonitoringFailed calls, queue depth and alerting watched as part of hypercare
The test schedule also changes the release conversation. Because a side-by-side extension is loosely coupled, Contoso can release the fleet app without an SAP S/4HANA transport, and can upgrade SAP S/4HANA without redeploying the app. That independence is only safe if contract tests run in both directions: on every app release against the current CMQ, and on every SAP S/4HANA change against the current app.
What would you do?
The fleet app passed all its UI tests. A week after go-live, the fleet desk reports that some inquiries appear twice. Logs show the same sales order changed event was delivered twice after a broker reconnect. What should Priya add to the test strategy?
- Test an extension as a small distributed system: logic, interfaces, platform configuration and business flow.
- Many fast service tests with mocks; contract tests for every consumed API and event; few, valuable end-to-end tests.
- Run contract tests in both directions: on extension releases and on SAP S/4HANA upgrades and support packages.
- Event-driven extensions need duplicate, out-of-order and outage tests.
- Sign-off evidence includes the interface list, contract results, integration results in test, and unhappy-path results.
Check your understanding · not graded
Lesson check
1. What does a contract test of a consumed API check?
2. When should contract tests run against CMQ?
3. What does it mean for an event handler to be idempotent?
4. Which evidence fits a data extension sign-off?