Test automation strategy: automating the right things
Suites get abandoned when they are slow, flaky or testing the wrong level. A deliberate strategy prevents all three.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- API tests are fast, stable and attributable — the best value layer.
- Unhappy paths, especially authorisation, catch the serious defects.
- Contract tests catch breaking changes at build time.
- Self-contained test data removes a major source of flakiness.
Why this layer pays
API tests exercise real business logic through a stable contract. They are fast, they do not break when the interface is restyled, and they fail with clear, attributable errors.
For most systems, moving coverage from end-to-end into the API layer improves both suite speed and reliability without reducing meaningful verification.
Test the unhappy paths
- Validation failures with malformed and boundary input.
- Authentication and authorisation, including access to another user's data.
- Missing and conflicting resources.
- Idempotency — the same request sent twice.
- Rate limiting and payload size limits.
The authorisation case deserves particular attention. Testing that a user can access their own data is routine; testing that they cannot access someone else's is what catches the serious defects.
Contract testing between services
In systems with several services, contract tests verify that a provider still satisfies what consumers expect, without running everything together.
This catches breaking changes at build time rather than in a shared environment, and it removes a common source of integration surprises.
Manage test data properly
Tests that depend on data someone created manually fail unpredictably. Each test should create what it needs and clean up, or run against a known seeded state.
Shared mutable test data is one of the main causes of flakiness, and it is entirely avoidable.
Testing failure of dependencies
Most integration defects appear when something downstream misbehaves, and most test suites only cover it behaving correctly.
Simulate the failures deliberately: a timeout, a slow response, a malformed payload, a 500, and a rate-limit response. Verify that your service degrades sensibly rather than propagating a confusing error or hanging.
This is straightforward with a mock or proxy and it catches a category of defect that is otherwise found in production during someone else's incident.
Frequently asked questions
They reduce how many you need. A small number of end-to-end tests covering critical journeys still verifies that the pieces work together.
Test your handling of their responses, including failures and timeouts, using recorded or simulated responses. Testing their availability is monitoring, not testing.
Generate request and response validation from the API specification so tests fail when the contract changes unexpectedly.
