Testing Through Layers: From Code to Infrastructure
- date
- category
- Testing
- also in
- CI/CD · Infrastructure · Reliability Engineering
- reading
- 2 min / 310 words
The worst bug after deployment rarely tells you which test was missing.
You only see the symptom:
tests are green
deployment is green
the application starts
the first real request breaks
That does not mean tests are pointless.
It usually means we tested too low, too high, or next to the risk.
Test as a gate
A test is not proof that the system is correct.
It is a filter:
this kind of failure did not pass through this gate
That is why test types only make sense when their place is clear.
A unit test catches a bug next to a code decision.
An integration test catches a bug at the boundary with a dependency.
A contract test protects a public agreement.
An E2E test checks whether a critical path really composes into a whole.
A migration test says whether data state can still change safely.
An infrastructure test checks whether the environment broke the application's assumptions.
The axis of the series
The series moves from the cheapest feedback to the most expensive:
code
|
v
component or module
|
v
real dependency
|
v
public contract
|
v
full user path
|
v
data, performance, and infrastructure
The point is not that every project must have every test everywhere.
The point is not to use one test type for every risk.
If E2E catches a typo in a mapper, the test is too high.
If a unit test pretends the database whose behavior is the source of the problem, the test is too low.
If the pipeline does not check migrations, rollback may be only hope.
What the parts cover
Each article takes one level or one close group of names and answers four questions:
what kind of test this is
which failure it should catch
what it cannot see
which tool I would use in my stack
The tools are concrete, but they are not the starting point.
First, the boundary needs a name.
Only then does it make sense to decide between Vitest, React Testing Library, Supertest, Testcontainers, Playwright, k6, Conftest, Trivy, or Kyverno.
By the end this should not be a list of tests.
It should be a map of quality gates.
Less "we have many tests".
More "we know where a given bug should be stopped".