Lesson 4 of 5
Designing interface test cases
10 min
Listen to this lesson
Most interface test packs are full of happy paths: a valid order arrives and creates a sales order. Those tests matter, but production interfaces fail on everything else: a field the partner leaves empty, a value nobody mapped, the same order sent twice, the receiver offline for an hour. Good interface test design covers mapping, validation and error handling deliberately.
Start from the interface specification
Every interface should have a specification: source and target fields, mapping rules, value mappings, mandatory fields, and what happens on error. If it does not, writing the tests will expose that gap fast. For Contoso's inbound customer order interface, the mapping says the customer's material number maps to CMC-ALT-100 through the customer-material information record, the customer's unit "EA" maps to pieces, and the requested delivery date maps to the order's requested date.
| Field in the customer's message | Mapping rule | Target in the sales order | Test |
|---|---|---|---|
| Customer material number | Customer-material information record | Product CMC-ALT-100 | Known number maps; unknown number is rejected clearly |
| Unit "EA" | Value mapping | Pieces | Quantity 50 EA arrives as 50 pieces |
| Requested delivery date | Direct mapping | Order's requested date | Same date, including month-end and year-end boundaries |
| Customer PO number | Direct mapping | Customer reference | Lands in the right field; a repeat is detected as a duplicate |
| Category | Test idea | Contoso example | Expected result |
|---|---|---|---|
| Mapping | Every mapped field arrives in the right target field | Customer PO number lands in the order's customer reference | Field-by-field match with the specification |
| Value mapping | Each mapped value converts correctly, including edge values | Unit EA becomes pieces; customer material maps to CMC-ALT-100 | Correct internal values |
| Mandatory fields | A required field is missing | No ship-to party in the message | Rejected with a clear error, or defaulted as specified |
| Invalid values | A value that does not exist in SAP | Unknown material number | Rejected with a clear error; reprocessable after correction |
| Duplicates | The same message twice | Same customer PO number sent again | Duplicate detected and handled as specified, no second order |
| Sequence | Messages in the wrong order | Change message arrives before the create | Held, rejected or processed as specified, never silently wrong |
| Volume and size | Many messages or one very large message | 300 orders in five minutes; an order with 500 lines | All processed within the agreed time |
| Receiver down | Target system unavailable | Middleware cannot reach SAP for 30 minutes | Messages queued and retried; nothing lost; alert raised |
Interface test categories with Contoso examples.
What a good error path looks like
An error-path test is not passed just because the bad message failed. It passes when the failure is handled the way the business needs. Write the expected result with all of these parts:
- Rejected safelyNo partial or wrong business document is created
- VisibleThe message appears in the right monitor with an error status
- UnderstandableThe error text says what is wrong in business terms
- NotifiedThe responsible team gets an alert or work item
- RecoverableAfter correction, the same message can be reprocessed without resending
Building the test data
For inbound interfaces, you need sample messages. Ask the partner or middleware team for real (scrambled) samples, then derive variants for each category. For IDocs, the test tool WE19 can copy an existing IDoc so you can change one segment value at a time. For APIs, a saved collection of requests with different payloads does the same job. Keep the samples under version control with the test cases, so a mapping change can be regression-tested in minutes.
Scramble samples taken from production before they enter your test repository. Interface messages carry the same personal data as the documents they create: contact names, phone numbers, delivery addresses and sometimes bank details. A sample library that quietly holds real customer data is a privacy problem, and it tends to be copied widely.
- Real sampleA message from the partner or middleware team.
- ScrambleRemove contact names, phone numbers, addresses and bank details.
- Baseline messageA valid order that passes, kept as the reference.
- Derive variantsCopy it in WE19 or a saved request; change exactly one value per negative test.
- Version controlStore the samples with the test cases for regression after mapping changes.
Master data and configuration behind the interface
Many interface failures are not mapping bugs but missing setup: a partner profile for a new partner, a customer-material information record, a unit of measure conversion, an output condition that should trigger the outbound IDoc. List these dependencies in the test case's preconditions, and check them in QAS before the cycle. When Contoso adds a second supplier to the EDI interface, the first test is whether the partner profile and output setup exist at all.
What would you do?
Contoso's integration test plan for the inbound customer order interface has 25 test cases, all with valid orders for different products. Priya can add five more. Which five add the most value?
- Derive interface tests from the specification: mapping, value mapping, mandatory fields, invalid values, duplicates, sequence, volume, receiver down.
- An error-path test passes only when the failure is safe, visible, understandable, notified and recoverable.
- Build negative messages from real samples, changing one thing at a time.
- Keep sample messages with the test cases for fast regression after mapping changes.
Check your understanding · not graded
Lesson check
1. Which interface test is an ERROR-PATH test?
2. What should happen when the same customer order message is received twice?
3. Why change only one thing in each negative test message?
4. When is a receiver-down test passed?