Testing Fundamentals
Problem
Your discount calculation passes its tests. Customers still cannot complete checkout because the payment service changed its response format. Testing one correct part does not establish that the whole system works.
Solution — Test Different Behaviors at Different Scopes
Choose the test according to the question you need answered:
- Unit: Does this function calculate the discount correctly in isolation?
- Integration: Can the order component actually read and write its database?
- Contract: Does an API still satisfy the request and response expectations of its consumers?
- End-to-end: Can a customer complete the purchase through the full workflow?
- Load: Does checkout meet its targets under a realistic expected workload?
- Stress: What happens when demand exceeds its designed capacity, and does it recover?
- Failure: What happens when a dependency times out or becomes unavailable?
Use controlled failure experiments with clear boundaries and a recovery plan. Combine fast, focused checks with broader tests of important workflows. A mock payment service is useful, but it can drift from the real service. Passing results apply to the tested cases and conditions; they cannot prove the absence of every defect.
Core idea: different tests answer different questions. Confidence comes from useful coverage of behavior, interactions, load, and failure.