Lesson 3 of 6
Virtualization and mocks
18 min
Listen to this lesson
Contoso's order-to-cash process depends on systems Contoso does not control. The carrier's tracking service has no test environment (its shipment booking interface has one, but it must be booked in advance). The bank's test system is available two days a week. The EDI partner for Great Lakes Fleet Services charges for test messages and needs a day's notice. If every automated test needs all of them, continuous testing becomes occasional testing. Service virtualization and mocks break that dependency by putting a controllable substitute where the real system would be.
A vocabulary of substitutes
| Substitute | What it does | Typical SAP use |
|---|---|---|
| Stub | Returns fixed answers to known requests | A carrier rate request always returns one rate |
| Mock | Returns answers and lets the test verify how it was called | Unit test checks that the CAP handler called the S/4HANA API once with the right key |
| Fake | A simplified working implementation | An in-memory version of a service used by CAP locally |
| Virtual service | A network-level substitute that behaves like the real system, often stateful and configurable | A virtual carrier tracking service that returns delivery events with realistic delays |
Kinds of substitutes, from simplest to richest.
At the code layer, SAP's frameworks already help. ABAP Unit supports test doubles for dependencies. CAP mocks imported remote services automatically when running locally: its documentation explains that a CDS service definition is enough to serve a working OData service, with sample data from CSV files, so extension logic can be tested without a connected S/4HANA system. At the interface layer, SAP's IDoc test tool (WE19) can create test IDocs and push them through inbound processing, which lets a test simulate a partner's inbound message without the partner.
When virtualization pays off
Virtualization is most useful when a partner system is unavailable, costly or nondeterministic in test, and when you need behavior the real system will not give you on demand: a timeout, a malformed response, a duplicate message, a rejection code. Those negative cases are often where SAP integration defects live, and they are nearly impossible to trigger against a real partner.
Keep substitutes honest: contracts
A substitute is only useful if it behaves like the real thing. The risk is a virtual service that drifts from the real interface, so tests pass against the virtual partner and fail against the real one. The ISTQB syllabus describes contract testing as the answer: the messages exchanged between services are captured in a contract that both sides are verified against. In the consumer-driven variant the consumer states its expectations; in the provider-driven variant the provider publishes how its service behaves. For SAP interfaces, the contract is often already there in a technical form: the OData $metadata document, the WSDL of a SOAP service, or the IDoc type definition.
- Capture the contractMetadata, WSDL, IDoc type, or recorded request and response pairs agreed with the partner.
- Build the virtual serviceImplement responses for normal and negative cases from the contract.
- Verify the virtual serviceCheck it against the contract on every change.
- Verify the real servicePeriodically run the same contract checks against the partner's test or sandbox endpoint.
- Detect driftIf the real service fails its contract check, update the contract and the virtual service together.
Routing to substitutes
Tests should switch between real and virtual dependencies by configuration, not by code changes. In S/4HANA, outbound calls go through destinations, logical ports and partner profiles; in BTP, through destinations; in CAP, through profiles that decide whether a remote service is mocked or bound to a real destination. Keep a routing table per environment: in the BTP pipeline test space everything external is mocked; in CMQ the carrier is virtual while the bank is real on Tuesdays and Thursdays; before release, the end-to-end rehearsal runs against every real partner test system available.
What would you do?
The carrier has no test environment and its production tracking service changes its response format twice a year without notice. Contoso's delivery tests fail unpredictably. What is the best approach?
- Substitutes range from stubs and mocks to fakes and stateful virtual services.
- Virtualize dependencies that are unavailable, costly or nondeterministic, and to force negative cases.
- CAP mocks remote services locally; WE19 simulates inbound IDocs; ABAP Unit supports test doubles.
- Contract testing keeps virtual services aligned with real ones; SAP metadata, WSDL and IDoc types are natural contracts.
- Route by configuration per environment, and always finish with real partner tests before release.
Check your understanding · not graded
Lesson check
1. Service virtualization is most useful when:
2. What keeps a virtual service from drifting away from the real interface?
3. Which SAP tool lets a test push a test IDoc through inbound processing without the partner?
4. Why should tests switch between real and virtual dependencies by configuration?