Lesson 3 of 6
Mocking remote services and testing contracts
10 min
Listen to this lesson
The fleet app depends on the Sales Order and Business Partner APIs and on sales order events. Mocking them lets service tests run anywhere in seconds. Contract tests make sure the mocks stay honest: that what the app expects from SAP S/4HANA is still what SAP S/4HANA provides. One without the other is a trap: mocks without contracts drift away from reality; contracts without mocks make every test depend on CMQ.
Mocking with CAP
Because cds import turns each API specification into a CDS service definition, CAP can serve a mock of it with no extra code. When the remote service has no credentials in the active profile, the test server mocks it in-process, with mock data loaded from .csv files such as API_SALES_ORDER_SRV-A_SalesOrder.csv into the same in-memory database. For a setup closer to production, cds mock serves the remote API in a separate process and the app connects to it over HTTP. CAP's documentation describes the imported APIs as contracts that let teams develop in parallel, each with the others' services mocked.
- Realistic data: orders with and without deliveries, partly delivered items, blocked orders, long names, empty optional fields.
- Known keys: test data uses agreed test values (for example the Great Lakes Fleet Services test customer), never copied production records.
- Failure behavior: for tests of time-outs and server errors, use a small test-only implementation of the remote service that rejects requests, kept apart from the normal mock.
- Event payloads: sample events built from the event reference on the SAP Business Accelerator Hub, including duplicates and out-of-order sequences.
What a contract test checks
A contract is the part of an interface a consumer actually relies on. For the fleet app, that is a short list: entity set A_SalesOrder with key SalesOrder, the fields SoldToParty, RequestedDeliveryDate, OverallDeliveryStatus and TotalNetAmount, their types, the filter on SoldToParty, and the navigation to items. A contract test compares that list with the provider. It runs at two points: against the stored specification in the pipeline (did our code start using something not in the spec?), and against the live metadata of CMQ on a schedule and after SAP S/4HANA changes (did the provider change something we use?).
- Record expectationsList the entity sets, keys, fields, types and operations the app uses; keep it next to the imported spec
- Check the codeIn the pipeline: every field the app queries exists in the stored spec and the list
- Fetch provider metadataOn a schedule and after support packages: read $metadata of the API in CMQ through the test destination
- CompareMissing entity set, field or key, or a changed type, fails the check with a clear report
- ActUpdate the app or raise the change with SAP before CMP gets the support package
Contract checks are deliberately narrow. They do not compare whole specifications, because SAP adds fields and entities in new releases without breaking consumers; a check that fails on every addition will soon be ignored. They check only what the app uses. For events, the same idea applies to the payload: the event type the app subscribes to, and the fields its handler reads from data, such as the sales order key.
| Mock-based service test | Contract test | Integration test | |
|---|---|---|---|
| Talks to | Mocked remote service | Stored spec, then provider metadata | Real CMQ through the real destination |
| Proves | The app's logic with the expected data shapes | The expected data shapes still exist | The landscape connects and authorizes |
| Runs | Every build | Every build and after SAP S/4HANA changes | After each deployment to test |
| Blind to | Changes in the real API | Business behavior and configuration | Most logic and edge cases |
What would you do?
SAP applies a support package to CMQ on Friday. On Monday, the fleet app's local tests are still green, but the sales order list in cmc-ext-test shows empty delivery status. Nobody knew until a tester noticed. What would have caught this earlier?
- CAP mocks imported services in-process from their CDS definitions, or in a separate process with cds mock.
- Mock data must be realistic; keep failure-behavior mocks separate and test-only.
- A contract is the part of an API or event the app relies on; record it next to the imported spec.
- Check contracts against the stored spec in the pipeline and against live metadata after SAP S/4HANA changes.
- Check only what the app uses, so additions by SAP do not cause false alarms.
Check your understanding · not graded
Lesson check
1. When does the CAP test server mock an imported remote service in-process?
2. What should a consumer contract for the Sales Order API contain?
3. Why should contract checks not fail when SAP adds a new field to an API?
4. Which test is blind to a changed field in the real API?