Lesson 19 · Senior testing practice

Mock senior testing interview pack

A retrieval-first mock pack for turning the whole testing course into clear, interview-grade answers you can say under pressure.

Your win: run a realistic senior testing mock interview on yourself, score your answers honestly, and turn weak spots into a concrete review plan.

In plain English Plain English: answer out loud before checking the answer points. Recognition is not recall.

How to get the most out of this page

This page works best if you treat it like a real interview, not a reading page. Answer first. Then check the points. Then answer again more cleanly.

That retrieval-first rhythm is important. The earlier lessons in this course were strongest when they kept forcing you to explain the idea in your own words before leaning on the summary. This page is trying to do the same thing, just under interview pressure instead of lesson pressure.

The format

The answer checklist A strong answer should usually include: (1) the model, (2) the main trade-off or risk, and (3) a repo-grounded consequence or example.

Round 1 · Foundations and strategy

  1. What makes a unit test valuable in this repo?
  2. Why does the testing pyramid matter?
  3. What is the point of t.Parallel() plus fresh suite setup?
  4. Why is coverage only a guide?
  5. What does -count=3 protect against?
Round 1 · Strong answer points
  1. Value. Fast isolated proof of real behavior at the cheapest reliable layer.
  2. Pyramid. It is a decision tool for where bugs should be caught first, not just a diagram.
  3. Parallel + fresh suite. They prevent hidden shared state and make repetition honest.
  4. Coverage. It can show gaps but cannot guarantee the right behaviors or error paths were tested.
  5. -count=3. It exposes flaky, order-dependent, or state-sharing tests.

Round 2 · Mocks, seams, and layer choice

  1. Why do interfaces matter for unit testing?
  2. When is a plain mock enough?
  3. When is testutil.MockDB the better choice?
  4. Why regenerate mocks after interface changes?
  5. How do you know a unit is too hard to test cleanly?
  6. What makes a mock expectation brittle?
Round 2 · Strong answer points
  1. Interfaces. They create seams that let tests substitute collaborators honestly.
  2. Plain mock. Best for orchestration and behavior verification.
  3. MockDB. Better when repository scan/query behavior needs stronger proof without a real DB.
  4. Regeneration. Generated mocks are part of the build truth; stale mocks misrepresent the current seam.
  5. Hard to test. It may indicate too many responsibilities or unclear boundaries, not just missing helpers.
  6. Brittleness. The expectation is tied to incidental implementation detail rather than the behavior the test needs to prove.

Round 3 · Senior review and failure judgment

  1. How do you review whether a test gives false confidence?
  2. What do you look for in a flaky test triage?
  3. How would you explain happy-path-only coverage as a PR comment?
  4. Why is “more realistic” not always a better test?
  5. How do you justify a heavier test outside the unit boundary?
  6. How would you summarize this repo’s testing philosophy honestly?
Round 3 · Strong answer points
  1. False confidence. Ask what behavior is actually proven, what remains unproven, and whether assertions are too weak or over-coupled.
  2. Flake triage. Check shared state, ordering, timing, reused mocks/contexts, and hidden randomness.
  3. Happy-path-only PR comment. Green is not enough; check the house error-path checklist and add missing failure cases.
  4. Realism trade-off. Heavier tests cost more and can be less deterministic; choose them only when smaller tests cannot prove the needed behavior honestly.
  5. Escalation. Use a heavier layer when lower layers cannot validate the boundary or infrastructure fact you care about.
  6. Repo philosophy. Fast isolated tests first, clear seams, behavior-focused assertions, regenerated mocks, repeatability under -count=3, and honest escalation only when needed.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off, risk, or repo consequence.
3I gave a strong, clear answer with model + trade-off/risk + repo consequence.
Recovery map — where to go next Missed core unit-testing shape? Revisit Lessons 1–4. Missed mocks and generators? Revisit Lessons 5–8. Missed layer testing and workflow? Revisit Lessons 9–12. Missed senior judgment? Revisit Lessons 13–18.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior testing answer?
recall, then click to reveal
A clear testing model, the important trade-off or risk, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior testing interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.