Comparison questionEasy~5 minStrategy & Boundaries / 1 of 5

Interview question

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat the suite as a portfolio of risks and feedback loops. PR tests should localize failures quickly; release checks can cover broader integration; safe post-deployment checks verify the environment. I also consider test data ownership, parallel execution, diagnostic artifacts, and how often the behavior changes. The goal is not a perfect pyramid shape. It is fast evidence for common changes and deeper evidence around expensive failure modes.

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.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The chosen test cannot reach the boundary most likely to fail.
A harmless refactor breaks many tests.
Slow tests run on every tiny edit with no risk distinction.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Where would you test authorization?
When is overlap between test levels useful?
What deserves an end-to-end test?

Continue the section

Next in Strategy & Boundaries: Valuable Unit Tests

Step 2 of 5

What makes a unit test valuable?

Opening drill

Comparison questionEasy~5 minStrategy & Boundaries / 1 of 5

Interview question

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

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.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I treat the suite as a portfolio of risks and feedback loops. PR tests should localize failures quickly; release checks can cover broader integration; safe post-deployment checks verify the environment. I also consider test data ownership, parallel execution, diagnostic artifacts, and how often the behavior changes. The goal is not a perfect pyramid shape. It is fast evidence for common changes and deeper evidence around expensive failure modes.

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.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The chosen test cannot reach the boundary most likely to fail.
A harmless refactor breaks many tests.
Slow tests run on every tiny edit with no risk distinction.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Where would you test authorization?
When is overlap between test levels useful?
What deserves an end-to-end test?

Continue the section

Next in Strategy & Boundaries: Valuable Unit Tests

Step 2 of 5

What makes a unit test valuable?

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 the section

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 the section