Skip to main content

Module Quiz

Complete this quiz after finishing the concept and practice paths. Questions are scenario-based: the right answer usually requires a judgment call plus a one-sentence defense.

Current Module Questions​

Question 1: Walking Skeleton vs MVP​

Your teammate argues that the walking skeleton should at least allow a user to create and view one task, because otherwise it delivers no value. What is wrong with this argument?

Answer: The teammate is describing a minimum viable product, not a walking skeleton. The skeleton's job is to prove every architectural layer and deploy seam works, even if the response delivers zero user value. Conflating the two usually leads to a skeleton that is so wide it takes three weeks to ship, defeating the purpose.

Question 2: Identifying the Steel Thread​

Given a capstone with three backlog stories -- (a) user login (auth only), (b) create a task (DB only), (c) sync tasks from GitHub (auth + DB + external API) -- which one should be the steel thread? Defend the choice.

Answer: (c). The steel thread is chosen to cover the most integration points, not the most user value. Story (c) touches all three, so shipping it first surfaces integration risks in auth, DB, and external-API at once -- buying the most information per unit of work.

Question 3: Test Pyramid Split Rationale​

Your capstone has 60 tests split as 30 unit / 20 integration / 10 E2E. Name two concrete risks this split introduces and recommend a correction.

Answer: Two risks: (1) E2E at ~17% makes CI slow and flaky; (2) unit at 50% is below the leverage band for most branchy domain code. Recommended correction toward a 70/25/5 shape (roughly 42/15/3): promote E2E coverage down to integration where feasible, and add unit tests on pure logic. Defend the move by pointing at specific E2E tests that could be integration tests.

Question 4: Choosing Test Level​

You are about to test a compute_overdue_tasks(tasks, now) pure function with five branches. At which level should you test it, and why not the other two?

Answer: Unit. It is pure logic with multiple branches, so unit tests have maximum leverage. Integration would add overhead without covering anything unit does not already cover. E2E would be wastefully slow and would not isolate which branch failed.

Question 5: Mock vs Fake vs Real​

In your integration test for a TaskRepository, you use a mocked database that returns a predetermined row. What kind of test is this actually, and why is that a problem?

Answer: It is a unit test with extra ceremony, not an integration test. It will not catch schema-drift, migration bugs, or ORM mis-mapping. The fix is to run against a real containerized DB (with transactional rollback) so the real seam is exercised.

Question 6: Coverage Floor vs Target​

A teammate proposes raising the coverage floor from 80% to 95%. You resist. Give one concrete argument against the change and one condition under which you would agree.

Answer: Against: pushing a floor to 95% tempts the team to add trivial tests (assertion-free or tautological) to hit the number, degrading suite quality. Agree if the team has shipped a tool that tracks mutation score alongside coverage, and 95% coverage is paired with a rising mutation score.

Question 7: Contract Test Necessity​

Your capstone integrates with the Stripe API. Your current tests mock Stripe. What does a Pact-style consumer-driven contract test add that your mock does not, and when would it fail?

Answer: It adds a recorded, shareable description of what your code expects from Stripe. Replayed against the real Stripe API on a schedule, it fails when Stripe changes response shapes -- something your mock cannot detect because it returns what you told it to. That failure alerts you to drift before production breaks.

Question 8: Triage in Under Ten Minutes​

A user reports: "When I click 'delete' on a task, the app sometimes shows a 500 error, and the task is still there after a refresh." Produce a triage entry with Sev, impact, and a suspected root-cause tag.

Answer:

  • Sev: Sev-2 (core feature partially broken; intermittent rather than total).
  • Impact: delete operation unreliable; users may leave stale tasks; no data loss reported, but UX eroded.
  • Suspected root-cause tag: concurrency or external-api/transient depending on architecture; in a stateless API, start with concurrency given the "sometimes" qualifier.
  • Reproduction: clicking delete repeatedly; check server logs for 500s.

Question 9: Regression-First on a Security Bug​

A Sev-1 authorization bug allows cross-tenant deletion. Describe the order of operations from triage to merged fix.

Answer:

  1. Triage (Sev-1, impact, tag authorization).
  2. Write the failing test at the cheapest reliable level -- typically an integration test that attempts a cross-tenant delete and asserts 403.
  3. Confirm the test fails for the right reason.
  4. Write the smallest code fix (tenant check in the authorization middleware or service boundary).
  5. Confirm the test passes and full suite is green.
  6. Commit test and fix together, link the triage id, merge with priority.

Question 10: Diagnosing Flakiness​

A unit test passes locally and fails 10% of the time in CI. Walk the five-cause checklist in order and pick the most likely cause first, with a one-line diagnostic step for each.

Answer:

  1. Timing/race -- unlikely for a pure unit test; diagnostic: log ordering of events.
  2. Shared mutable state -- possible if tests touch a module-level singleton; diagnostic: run test alone.
  3. External non-determinism -- unlikely in a unit test; diagnostic: run offline.
  4. Test-order dependency -- most likely given CI-only failure; diagnostic: randomize order locally and CI.
  5. Environment leakage -- possible if env var presence changes behavior; diagnostic: compare local env vs CI env.

Start with test-order given the symptom.

Question 11: Boy-Scout vs Deep Refactor​

You notice, mid-PR, that TaskService has two methods that share 40 lines of tag-handling code. What is the correct response?

Answer: This is beyond a 15-minute boy-scout move. Add a debt ledger entry naming Extract Class (pull tag handling into TagService) as the proposed refactor, finish the feature PR cleanly, and schedule a deep-refactor window this week or next. Do not derail the current PR to execute the refactor.

Question 12: Self-Review Comment Quality​

Rewrite this self-review comment so that it is specific, evidence-based, and actionable: "this function feels off".

Answer: Example rewrite: "task_svc.py:58 -- Clarity: t is used as both the incoming payload and the saved row; rename to payload vs saved. Also, this function now mixes validation and persistence. Suggest Extract Function on the validation block or, if it grows, move validation to a service boundary."

Question 13: Ledger Trigger Discipline​

Your ledger has this entry: "Error translation is ad-hoc across endpoints. TODO: fix eventually." What is wrong and how do you fix it?

Answer: It has no trigger. "Eventually" is not a trigger. Replace with something concrete, e.g., "fix before week 7 polish pass, OR immediately if a second endpoint leaks internal errors, OR before any public release." Without a trigger, the entry is noise and will never be acted on.

Question 14: 70/25/5 Under Pressure​

Your CI is now over 8 minutes. Investigation shows the E2E suite alone is 6 minutes. Propose a concrete action that preserves delivery safety.

Answer: Most gains come from moving coverage from E2E down to integration. Audit each E2E test: can it be replaced by one or two integration tests at one-tenth the cost? Cut the E2E count to the 2-5 money-path flows defended in the test plan. Quarantine any flaky E2E tests with tickets, not retries. Target: CI under 3 minutes.

Question 15: Defending the Ship Decision​

At week 6, you have one Sev-3 ledger entry that is embarrassing but not dangerous, and two Sev-1 integration bugs still open. What do you ship, what do you block on, and why?

Answer: Ship with the Sev-3 ledger entry recorded and a trigger set ("fix in next release window, or immediately if a second endpoint is affected"). Block the release on both Sev-1 bugs: they meet the shipping-gate condition (data/security/integrity risk). Defend by pointing at the triage entries and the ledger. The ledger is the mechanism that makes this decision defensible.

Interleaved Review Questions​

Prior Module Question 1 (S10 M1)​

Why does a one-page ADR improve the capstone even when you are the only engineer?

Answer: Six months from now your future self will not remember which alternatives were considered or why a decision was made. The ADR is a message to that future self (and to anyone reading the portfolio). It also forces the writer to name alternatives, which catches premature commitment.

Prior Module Question 2 (S9)​

Name one engineering habit from your prior testing track that this module extends, and one that it sharpens.

Answer: Extends: TDD for new code becomes regression-first for defects. Sharpens: the test pyramid goes from "concept" to "opinionated 70/25/5 with written rationale on your capstone."

Prior Module Question 3 (S8)​

Why is observability (prior track) relevant even in a walking skeleton?

Answer: Because the skeleton is the cheapest opportunity to wire a structured log line or a trace span into the request path. Observability added at skeleton time is free; added later, it requires a refactor.

Prior Module Question 4 (S7)​

How does strong type discipline from earlier semesters change the role of the type checker gate in this module?

Answer: It makes the type-checker gate cheap: if code is already written with types in mind, the gate catches genuine regressions instead of fighting against untyped code. Skipping the gate would waste the investment already made.

Prior Module Question 5 (S6 M4)​

Given what you know about transactions and consistency, why is an integration test that uses a mocked DB actively misleading?

Answer: Because transaction boundaries, isolation levels, constraint checks, and consistency guarantees are only real when a real transactional system runs. A mock cannot represent them. So the mocked test may pass while the real system loses or duplicates data.

Self-Assessment and Remediation​

Scoring and Advancement Criteria​

Mastery (90-100% correct):

  • Ready to advance to Module 3. Maintain the habits; revisit only the cluster where a question was missed.

Proficient (75-89% correct):

  • Review the specific concept page corresponding to each missed question. Redo the practice drill that covers the weak cluster.

Developing (60-74% correct):

  • Rework the walking-skeleton lab and the test-strategy workshop. Re-read Concepts 4, 5, 6, 10, 11, 12 carefully. Redo the katas.

Insufficient (<60% correct):

  • Return to S3 M05 Applied Design & Code Review, your prior-semester testing notes, and the concept sequence in order. The capstone cannot safely progress without these habits.

Remediation Pathways by Cluster​

If missed Cluster 1: re-run the Walking Skeleton Lab and deploy the result to staging. If missed Cluster 2: redo the Test Strategy Workshop and commit the plan. If missed Cluster 3: redo the Quality Gates Clinic and ensure each gate is blocking. If missed Cluster 4: redo Katas 1 and 3; run 100 randomized runs of your suite and diagnose any flakes. If missed Cluster 5: redo Katas 2 and 4; audit your debt ledger against the trigger rule.