Lesson 1 of 6
A test strategy for extensions
9 min
Listen to this lesson
Contoso's fleet order status app is small: a CAP service, an SAP Fiori elements UI, two consumed SAP S/4HANA APIs, one event subscription and a handful of roles. It still fails in many different ways: a handler rule can be wrong, an SAP S/4HANA support package can change an API, a destination can point to the wrong system, a role collection can be missing, or an event can arrive twice. Priya's strategy gives each kind of failure a test level that finds it as early and cheaply as possible.
Match failures to levels
| What can go wrong | Cheapest level that finds it | Where it runs |
|---|---|---|
| Validation or handler rule is wrong | Service test | Developer machine and pipeline |
| Authorization annotation missing or wrong | Service test with mocked users | Pipeline |
| Consumed API field renamed or removed | Contract test | Pipeline against stored spec; scheduled against CMQ |
| List report shows wrong columns or filters | OPA5 test | Pipeline in a headless browser |
| Destination, Cloud Connector or trust misconfigured | Integration smoke test | cmc-ext-test after each deployment |
| Process across SAP S/4HANA and app breaks | End-to-end test | cmc-ext-test with CMQ client 100 |
Each failure type and the cheapest test level that can catch it.
The ratio matters. If most checks sit at the top, every test cycle depends on CMQ being available, test data being right and the Cloud Connector being up, and each failure takes hours to diagnose. CAP's own testing guide gives a further warning that applies at every level: the more you mock, the less you test the real thing. The answer is not to avoid mocks, but to know exactly which risks each level covers, and to cover the remaining ones higher up.
Entry and exit criteria
- Entry to integration testing: service, UI and contract tests green in the pipeline; app deployed to cmc-ext-test by transport; destinations verified against CMQ client 100.
- Entry to end-to-end testing: integration smoke tests green; test data prepared in CMQ; test identities per role in the right groups.
- Exit for release: no open critical or high defects; agreed end-to-end scenarios passed with evidence; authorization negative tests passed; contract tests passed against CMQ's current support package.
- Recorded in SAP Cloud ALM: test cases, test plans, results and defects, linked to the requirement, as for the rest of the S/4HANA program.
What would you do?
A project manager proposes skipping automated tests for the fleet app and running all testing as manual end-to-end scenarios in cmc-ext-test, "because that is what users will do". What should Priya answer?
- Give each failure type the cheapest level that catches it: service, UI, contract, integration, end-to-end.
- Most tests should be fast service tests; a few end-to-end scenarios provide sign-off evidence.
- Mocks speed things up but leave risks uncovered; cover those higher up.
- Define entry and exit criteria per level, including contract and authorization results.
- Record test cases, plans, results and defects in SAP Cloud ALM with the rest of the program.
Check your understanding · not graded
Lesson check
1. Which level should catch a wrong validation rule in a CAP handler?
2. Which failure can only be found in the deployed test subaccount?
3. What is a sound exit criterion for releasing an extension?
4. What is the risk of putting most tests at the end-to-end level?