Architecture scenarioMedium~10 minTesting & Quality / 4 of 20

Interview question

A pull request changes authentication, a database migration, and a small UI label. How would you choose test coverage?

Choose test coverage from change risk

Builds a proportionate test plan from blast radius, failure probability, detectability, and reversibility.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I separate the change by impact. The UI label needs a focused component or visual check if layout matters. Authentication needs policy and endpoint integration tests for anonymous, allowed, and denied users. The migration needs compatibility, data-shape, and rollback or roll-forward checks against a realistic database. I would not give all three parts the same gate.

Full answer below

Practice focus

Risk assessment, layered coverage, migrations, security, release checks, and proportionality.

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
Real changes rarely deserve identical test depth. This question checks whether test effort follows risk rather than habit or raw line coverage.
I separate the change by impact. The UI label needs a focused component or visual check if layout matters. Authentication needs policy and endpoint integration tests for anonymous, allowed, and denied users. The migration needs compatibility, data-shape, and rollback or roll-forward checks against a realistic database. I would not give all three parts the same gate.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I also consider likelihood, detectability, and reversibility. A mistake in auth can expose data before monitoring notices, so I test negative paths directly. A migration can be hard to reverse, so I verify old and new application versions during rollout where relevant. The plan should name the failure each test protects, not just list test categories.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For delivery, I connect the risk map to pipeline stages: fast checks on the PR, realistic migration and integration checks before release, then safe smoke tests and metrics after deployment. I would keep the build artifact traceable and define the signal that stops or rolls back the release. For example, an unexpected authorization-denial spike can halt rollout even when every pre-release test passed. Later incidents and escaped defects should update this risk model so the suite follows evidence rather than becoming a permanent checklist.

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

Requiring the same suite for every change.
Testing only happy-path authentication.
Running migration tests against a toy provider.
Using coverage percentage as the risk plan.

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

Details

High-impact negative paths are untested.
No one can name what a test would catch.
Irreversible changes have no realistic verification.

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.

What would you run on every PR?
How would you test migration compatibility?
What belongs after deployment?

Continue the section

Next in Testing & Quality: xUnit Fixtures

Step 5 of 20

Structure xUnit tests and fixture lifetimes

Opening drill

Architecture scenarioMedium~10 minTesting & Quality / 4 of 20

Interview question

A pull request changes authentication, a database migration, and a small UI label. How would you choose test coverage?

Choose test coverage from change risk

Builds a proportionate test plan from blast radius, failure probability, detectability, and reversibility.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Risk assessment, layered coverage, migrations, security, release checks, and proportionality.

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
Real changes rarely deserve identical test depth. This question checks whether test effort follows risk rather than habit or raw line coverage.
I separate the change by impact. The UI label needs a focused component or visual check if layout matters. Authentication needs policy and endpoint integration tests for anonymous, allowed, and denied users. The migration needs compatibility, data-shape, and rollback or roll-forward checks against a realistic database. I would not give all three parts the same gate.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I also consider likelihood, detectability, and reversibility. A mistake in auth can expose data before monitoring notices, so I test negative paths directly. A migration can be hard to reverse, so I verify old and new application versions during rollout where relevant. The plan should name the failure each test protects, not just list test categories.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
For delivery, I connect the risk map to pipeline stages: fast checks on the PR, realistic migration and integration checks before release, then safe smoke tests and metrics after deployment. I would keep the build artifact traceable and define the signal that stops or rolls back the release. For example, an unexpected authorization-denial spike can halt rollout even when every pre-release test passed. Later incidents and escaped defects should update this risk model so the suite follows evidence rather than becoming a permanent checklist.

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

Requiring the same suite for every change.
Testing only happy-path authentication.
Running migration tests against a toy provider.
Using coverage percentage as the risk plan.

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

Details

High-impact negative paths are untested.
No one can name what a test would catch.
Irreversible changes have no realistic verification.

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.

What would you run on every PR?
How would you test migration compatibility?
What belongs after deployment?

Continue the section

Next in Testing & Quality: xUnit Fixtures

Step 5 of 20

Structure xUnit tests and fixture lifetimes

A pull request changes authentication, a database migration, and a small UI label. How would you choose test coverage?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A pull request changes authentication, a database migration, and a small UI label. How would you choose test coverage?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section