FDE Foundations · Module 4: Software Craft
Testing in Customer Environments
Your code runs in an environment you do not control, against systems you did not build. Tests must imitate that reality: real shapes, real failure modes, sanitized data.
10 min reading
Objectives
- Build a test pyramid that fits a small service
- Use contract tests against real external systems
- Create fixtures from real (sanitized) customer data shapes
The pyramid, scaled down
For a small integration service: unit tests around the mapping and business logic, a handful of integration tests against local dependencies (containers or fakes), and a few end-to-end smoke tests you run in staging. You cannot afford a thousand end-to-end tests; you can afford good ones.
Contract tests
The riskiest boundary is the external system's API. Contract tests pin the parts you depend on: response shape, status codes, pagination behavior. Run them on a schedule, not only in CI, because external APIs drift without telling you. When a contract test fails, your integration broke upstream and you find out before the customer does.
Fixtures from reality
Ask for sanitized samples early: ten messy invoices beat a thousand clean ones. Build fixtures from them, including the malformed cases: empty files, wrong encodings, duplicates. A parser that has never seen the customer's real edge cases is a parser that will page you in month two.
Testing is not about proving the code works. It is about rehearsing the ways it will fail.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
List the test plan for a fictional webhook receiver: three unit test areas, two contract tests, three end-to-end cases, and the five malformed fixtures you would request from the customer.
Pass criteria
All three layers populated, contract tests state what they pin and the schedule, and the fixture list includes at least three genuinely malformed cases.