Choosing test data that would fail

Nulls, empty collections, maximum lengths, non-Latin names, one record with forty lines. Data chosen to BREAK the flow rather than to demonstrate it. Test data is normally built to prove the integration works, which means it is built to be easy. One clean invoice, two lines, an English supplier name, every field populated. It passes, and it tests almost nothing. THE SET THAT FINDS DEFECTS IS BUILT WITH THE OPPOSITE INTENT, and it is not long. NULLS AND MISSING OPTIONAL FIELDS. The commonest production failure by a wide margin: a field the sample always had, absent on a real record. Module 5's territory, and the mapping either handles it or produces something the target rejects. AN EMPTY COLLECTION. An order with no lines. A query returning zero rows. Loops over empty sets are a silent success — the flow completes having done nothing, which this course has already recorded as…

In this module: Module 15 · Testing an integration properly

1. 1What "tested" means for an integration
2. 2Testing without the other systemFree preview
3. 3Choosing test data that would fail
4. 4Testing the failure paths
5. 5Testing idempotency explicitly
6. 6End-to-end with the business
7. 7What breaks: the UAT that proved nothing
8. 8Lab briefing · A test plan somebody would sign