How do you decide whether a change needs a unit, integration, contract, component, or end-to-end test?

Choose the right test level for a change

Explains how unit, integration, contract, component, and end-to-end tests cover different failure boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I start with the behavior and the boundary that could fail. Pure business rules fit unit tests. Framework wiring, persistence, serialization, or authentication need integration tests. Contracts protect compatibility between services, component tests protect UI behavior, and a few end-to-end tests protect critical user journeys. I prefer the lowest test level that can fail for the right reason.

Full answer below

Practice focus

Test boundaries, feedback speed, confidence, failure localization, and risk-based selection.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Interviewers ask this because adding tests is easy; choosing the cheapest test that can reveal the real failure is the engineering decision.
I start with the behavior and the boundary that could fail. Pure business rules fit unit tests. Framework wiring, persistence, serialization, or authentication need integration tests. Contracts protect compatibility between services, component tests protect UI behavior, and a few end-to-end tests protect critical user journeys. I prefer the lowest test level that can fail for the right reason.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would not force every change into one layer. A pricing rule may have many fast unit cases plus one integration test proving persistence and API mapping. An authentication change deserves direct policy tests and a small browser or API flow because configuration and middleware order matter. Overlap is justified where the impact is high, but repeating the same assertion at five layers adds cost without much confidence.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling every test an integration test.
Using browser tests for pure domain rules.
Mocking framework behavior instead of exercising it.
Adding duplicate assertions at every layer.

How do you decide whether a change needs a unit, integration, contract, component, or end-to-end test?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement