Module 2: Implementation & Testing: Case Studies
These case studies turn the capstone implementation phase into a controlled delivery system: vertical slices, test strategy, contract tests, defects, and technical debt.
Case Study 1: Walking Skeleton Before Layers
Scenario: The first week builds database schema, auth, UI components, and service classes, but nothing runs end to end.
Source anchor: Martin Fowler's The Practical Test Pyramid reinforces proving real user paths early instead of accumulating isolated layers.
Module concepts: walking skeleton, vertical slice, integration test, MVP.
Wrong Approach
Build complete layers before proving one path.
Better Approach
Ship one thin path:
UI form -> API endpoint -> database write -> dashboard row -> deployed smoke test
Failure Mode
The capstone appears busy but never becomes operable, so integration bugs and deployment gaps surface late when schedule pressure is highest.
Project / Capstone Connection
Use this to define the first end-to-end slice your capstone must run in development and CI before broad feature work begins.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Layer-first buildout | parallel-looking progress | delayed integration proof | interfaces are already stable and well known |
| Walking skeleton first | early system proof | less immediate breadth | the capstone still has integration uncertainty |
Required Artifact
Define the walking skeleton path, its acceptance test, and what it proves.
Case Study 2: Test Pyramid For One Capstone
Scenario: The project has 80 brittle end-to-end tests and almost no unit or integration tests. Every change breaks CI.
Source anchor: Fowler's practical test pyramid article is the anchor for balancing fast unit feedback, boundary checks, and a small set of end-to-end tests.
Module concepts: unit, integration, end-to-end, test pyramid, feedback speed.
Wrong Approach
Test everything through the browser.
Better Approach
Allocate tests:
Unit:
domain rules and pure functions
Integration:
database repositories and external API adapters
E2E:
only critical user journeys
Failure Mode
Feedback becomes slow and noisy, CI trust erodes, and developers stop learning from failures because too many tests break for the wrong reasons.
Project / Capstone Connection
Use this to justify how your capstone test suite earns confidence without becoming a maintenance trap.
Tradeoff Table
| Test level emphasis | Benefit | Cost | Better fit when |
|---|---|---|---|
| Heavy E2E | high realism | brittle, slow, expensive | only a few end-user flows matter and infra is stable |
| Balanced pyramid | faster feedback and clearer failures | more upfront design of seams | you need repeatable CI during active iteration |
Required Artifact
Write a capstone test strategy table: behavior, test level, fixture, owner, CI gate.
Case Study 3: Contract Test For External API Adapter
Scenario: The capstone integrates with GitHub or Stripe. Local tests mock responses that do not match the real API, so production breaks.
Source anchor: Pact's Writing Consumer tests shows how consumer expectations can pin the adapter contract to fields your capstone actually depends on.
Module concepts: consumer-driven contract, mock fidelity, API adapter.
Wrong Approach
Use hand-written mocks with no contract.
Better Approach
Define the consumer expectation:
Given:
repository has open PRs
When:
client requests pull requests
Then:
response contains id, title, author, timestamps, review state
Failure Mode
The adapter passes local tests but fails against the real provider because mocked payloads ignored required fields, shapes, or status behavior.
Project / Capstone Connection
Use this when your capstone depends on an external API whose schema and edge cases you do not fully control.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Hand-written mocks only | fast setup | weak fidelity | the dependency is trivial and failure impact is low |
| Contract tests | better adapter confidence | extra setup and pact maintenance | the capstone depends on a provider boundary |
Required Artifact
Write one contract test scenario and the adapter behavior it protects.
Case Study 4: Flaky Test Triage
Scenario: A CI test fails once every ten runs. The learner reruns until green and moves on.
Source anchor: Google engineering guidance treats reliable tests as part of maintainable feedback loops, so flakiness is a defect to diagnose rather than noise to ignore.
Module concepts: flaky test, isolation, timing, CI reliability.
Wrong Approach
Rerun until green.
Better Approach
Triage:
failure signature:
timeout / order / shared state / clock / network
quarantine:
only with ticket and owner
fix:
deterministic fixture or wait condition
Failure Mode
The team normalizes randomness in CI, masks real regressions, and loses the ability to claim the capstone is tested with discipline.
Project / Capstone Connection
Use this for any capstone test that intermittently fails in CI or on another machine and therefore weakens your evidence story.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Rerun and ignore | low immediate effort | hidden regressions and low trust | almost never |
| Triage and fix | stable signal | debugging time now | the test guards an important path or release gate |
Required Artifact
Write a flaky-test incident note with reproduction, suspected cause, fix, and regression guard.
Case Study 5: Technical Debt Ledger That Has Consequences
Scenario: The learner writes "clean this later" comments but never records cost, risk, or trigger.
Source anchor: The debt ledger should work like a lightweight ADR: record why the shortcut exists, what risk it creates, and what signal forces revisit.
Module concepts: technical debt, risk, trigger, schedule.
Wrong Approach
Debt is a vague TODO.
Better Approach
Record:
Debt:
GitHub ingestion is synchronous
Reason accepted:
MVP speed
Risk:
slow provider response blocks request
Trigger:
if p95 ingest exceeds 2s, move to async job
Failure Mode
Shortcuts pile up without ownership, and the capstone accumulates hidden operational risk that nobody can explain or prioritize.
Project / Capstone Connection
Use this to track the shortcuts you knowingly accept in your capstone so they remain defensible during review.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Untracked TODO debt | zero process overhead | no prioritization or defense story | never for material shortcuts |
| Debt ledger with trigger | explicit risk management | small writing overhead | the shortcut affects reliability, performance, or maintainability |
Required Artifact
Write five debt ledger entries with accepted reason, risk, trigger, and cleanup plan.
Source Map
| Source | Use it for |
|---|---|
| The Practical Test Pyramid | deciding test granularity and feedback speed for the capstone suite |
| Pact consumer tests | defining consumer expectations for external API adapters |
| Google Engineering Practices | reinforcing disciplined review and test hygiene expectations |
Completion Standard
- Walking skeleton is implemented and tested.
- Test strategy table is complete.
- At least one contract or adapter test exists.
- Debt ledger has triggers and owners.