Lesson 4 of 5
Error, volume, recovery
9 min
Listen to this lesson
Happy-path tests prove an interface works on a good day. Production has bad days: malformed messages, month-end peaks, partner outages, expired certificates, a queue blocked behind one bad entry. Resilience tests prove the interface fails safely, copes with volume, and recovers without losing or duplicating business transactions. They are the tests most often cut when time runs short, and the ones whose absence shows first in hypercare.
Error tests
Error tests feed deliberately bad input and check the handling, not just the failure. The expected result has five parts: no wrong business document is created, the message shows as failed in the right monitor, the error text names the problem in business terms, the right owner is alerted, and the same message can be reprocessed after correction. Change exactly one thing per negative message, so you know which validation fired.
| Error test | Contoso example | Expected handling |
|---|---|---|
| Invalid value | Unknown product number from Great Lakes Fleet Services | Rejected with a clear message; routed to Maria's team; reprocessable |
| Missing mandatory field | No ship-to in the order | Rejected or defaulted exactly as specified |
| Duplicate | Same customer PO number sent twice | Second message detected; no second sales order |
| Out of sequence | Order change arrives before the order | Held, rejected or processed as specified, never silently wrong |
| Unmapped code | New unit code not in the value mapping | Fails visibly at Contoso, not days later at the partner |
Error tests for Contoso's order interfaces.
Volume and performance tests
Volume tests replay realistic peaks: Contoso's month-end order surge, the Thursday payment run, the Monday morning backlog after a weekend. Use production statistics to set volumes, and include message size, not just count; one order with 500 items behaves differently from 500 orders with one item. Measure end-to-end time, not just middleware time, and watch for queues that grow and do not drain. Agree pass marks before the test, such as "all month-end orders in S/4HANA within 20 minutes of receipt".
Recovery tests
- BaselineOrders flow normally from CMQ to Lakeside's test intake through the test tenant.
- Inject the failureLakeside's test SFTP server is stopped for 45 minutes while orders keep coming.
- ObserveMessages retry with backoff; nothing is lost; the alert fires when retries pass the agreed threshold.
- RestoreThe server comes back; queued orders deliver in order.
- ReconcileCount sent equals count received; no duplicates; times recorded.
Recovery tests simulate failure on purpose: receiver down, middleware unavailable, Cloud Connector restarted, a certificate replaced with an expired one in the test tenant, an S/4HANA queue blocked by a failing entry. Each one must show three things: the failure is detected and alerted, nothing is lost, and normal processing resumes without duplicates. Coordinate with Sam's Basis team for infrastructure failures, and with the partner for outages on their side.
Operational tests
The last group proves the interface can be run by the people who will run it: alerts reach named owners, the reprocessing procedure works as written when followed by someone who did not write it, the daily reconciliation finds a planted gap, and cutover steps (stop, drain, reconnect, smoke test) work in the mock conversions and dress rehearsal.
What would you do?
Time is short before the final test cycle. Grace proposes cutting recovery tests for the supplier order interface because "Integration Suite retries automatically anyway." How should Priya respond?
- Error tests check handling: safe, visible, understandable, alerted, reprocessable.
- Volume tests use production peaks, message sizes and agreed pass marks.
- Recovery tests inject failures and prove detection, no loss and clean resumption.
- Operational tests prove alerts, reprocessing, reconciliation and cutover steps work for the real operators.
Check your understanding · not graded
Lesson check
1. Which test proves an interface recovers after a receiver outage?
2. Where should volume test figures come from?
3. What three things must every recovery test show?
4. Who should run the reprocessing procedure in an operational test?