Module 2: Implementation & Testing
Core references: The Pragmatic Programmer and your own earlier semesters -- no new required books. Selective external support: Fowler's bliki, Dan North on BDD, Pact contract-testing docs, Fowler's refactoring catalog, Google's eng-practices, and one or two flaky-test post-mortems.
This module is the capstone counterpart to everything you already learned about writing, testing, and sustaining code. The job here is not to learn new theory. The job is to apply that theory to one real project under real delivery pressure.
Scope of This Module
This module is not a second tour of TDD, patterns, or CI configuration. It is where all of those habits meet a single capstone codebase that has to run, pass tests, survive review, and ship.
What it covers in depth:
- starting with a walking skeleton and vertical slices instead of complete layers
- choosing where unit, integration, end-to-end, and contract tests actually earn their keep on the capstone
- pre-commit hygiene, coverage floors, and lint gates as defaults, not optional polish
- bug triage, regression-first fixing, and flaky-test diagnosis in a system you own
- refactoring cadence and a self-administered code review during solo capstone work
- writing a technical-debt ledger that records what you chose not to fix and why
What it deliberately does not try to reteach:
- TDD fundamentals already covered in prior semesters
- framework-specific test runner configuration
- CI/CD pipeline design (Module 3 of this semester)
- monitoring and SLOs (Module 4 of this semester)
This is an integrative, applied module. If you can recite test-pyramid definitions but cannot say which tests go where in your own capstone, you are not done.
Before You Start
Answer these closed-book before starting the main path:
- What is the difference between a walking skeleton and a minimum viable product?
- Which three test levels does the test pyramid name, and why is the shape a pyramid?
- When is a contract test cheaper than spinning up the real external system in a test?
- What is the first question you ask when a test fails intermittently on CI but passes locally?
- What goes in a technical-debt ledger entry besides "this is ugly"?
Diagnostic Interpretation
4-5 solid answers
- You are ready for the full path.
2-3 solid answers
- Continue, but expect extra time in the test-strategy cluster and the flaky-test concept.
0-1 solid answers
- Revisit the testing track from Semesters 3 and 6 before continuing. This module assumes those habits are already in place.
What This Module Is For
Implementation and testing in a capstone is where delivery risk is actually controlled. The questions the module has to help you answer are:
- where does the thinnest end-to-end slice of my capstone go, and what does it prove?
- how many tests of each kind do I owe this project, and why?
- which quality gates must block a merge, and which can stay advisory?
- how do I handle a defect without breaking the rest of the codebase or my schedule?
- how do I keep the code livable for six more weeks without either polishing endlessly or drifting into a swamp?
This module builds the judgment needed to:
- ship a defensible first vertical slice in week 1 of capstone implementation
- write a test plan that splits effort by level and justifies it out loud
- survive integration with a real external system without flakiness ruining CI
- reduce defect rates by tightening the feedback loop, not by heroics
- exit the capstone with a codebase you would still accept a pull request against
You are learning to deliver one real system to the quality bar a junior engineer at a good company would be asked to meet.
Concept Map
How To Use This Module
Work the clusters in order. The later clusters assume the earlier ones are already shipped in code, not only understood in theory.
Cluster 1: Walking Skeleton First
| Order | Concept | Type | Focus |
|---|---|---|---|
| 1 | Walking Skeleton: The Thinnest End-to-End Slice | PRIMARY | Prove the full pipeline runs before anything else is built |
| 2 | Vertical Slices Over Horizontal Layers | PRIMARY | Ship user-visible behavior, not separate layers |
| 3 | Steel Thread: Proving Integration Before Polish | PRIMARY | The one thin path that forces every seam to line up |
Cluster mastery check: Can you point at your capstone repo and name the single walking-skeleton request, what it returns, and which layers it traverses?
Cluster 2: Test Pyramid for a Real System
| Order | Concept | Type | Focus |
|---|---|---|---|
| 4 | Unit Tests: Where They Add Real Leverage | PRIMARY | Fast, focused tests on the risky parts of pure logic |
| 5 | Integration Tests: Boundaries to Test, Fakes to Use | PRIMARY | Exercise real seams, fake what you do not own |
| 6 | End-to-End Tests: The Expensive Few | PRIMARY | A small, stable set that protects the money paths |
Cluster mastery check: Can you commit to an opinionated split (for example 70/25/5) for your capstone and defend it in three sentences?
Cluster 3: Quality Gates and Feedback
| Order | Concept | Type | Focus |
|---|---|---|---|
| 7 | Pre-Commit Hygiene: Formatting, Linting, Type Checks | PRIMARY | The no-debate baseline before any test runs |
| 8 | Coverage as a Floor, Not a Target | PRIMARY | What coverage does and does not tell you |
| 9 | Contract Tests When Integrating External Systems | PRIMARY | Consumer-driven contracts for APIs you do not own |
Cluster mastery check: Can you list the gates that must block a merge in your capstone repo, each with one sentence on why it is there?
Cluster 4: Defect Reduction Under Pressure
| Order | Concept | Type | Focus |
|---|---|---|---|
| 10 | Bug Triage Discipline: Sev, Impact, Root-Cause Tag | PRIMARY | Turning a bug report into a decision |
| 11 | Regression-First Fixing: Test That Fails, Then Code That Passes | PRIMARY | Never fix without a test that proves the fix |
| 12 | Flaky Test Diagnosis and Recovery | PRIMARY | Five common causes and how to kill each one |
Cluster mastery check: Given one capstone defect report, can you triage, write a failing regression test, and close the loop in one session?
Cluster 5: Keeping the Code Livable
| Order | Concept | Type | Focus |
|---|---|---|---|
| 13 | Refactoring Cadence During Capstone: Boy-Scout + Occasional Deep | PRIMARY | Small continuous cleanups plus short deliberate refactor windows |
| 14 | Code Review With Yourself: The 24-Hour Read-Through | PRIMARY | A solo version of the reviewer's rubric one day later |
| 15 | Technical-Debt Ledger -- Not Everything Gets Fixed | SUPPORTING | A written list with severity and why-deferred |
Cluster mastery check: Can you open your debt ledger and defend every entry: either "we will fix this in week X" or "we will ship with this, because..."?
Then work these practice pages:
| Order | Practice path | Focus |
|---|---|---|
| 1 | Walking Skeleton Lab | Scaffold the vertical slice for the capstone |
| 2 | Test Strategy Workshop | Decide which tests go where; produce the capstone's test plan |
| 3 | Quality Gates Clinic | Wire pre-commit, lint, and coverage floors in the capstone repo |
| 4 | Implementation Katas | Regression test, pattern-named refactor, flaky-test diagnosis, ledger entry |
Use Module Quiz after the concept and practice path. Use Reference and Learning Resources for cross-semester escalation only.
Learning Objectives
By the end of this module you should be able to:
- Scaffold a walking skeleton for the capstone: a single request that crosses every layer end-to-end.
- Slice work vertically into small user-visible increments instead of completing isolated layers.
- Choose a defensible unit / integration / end-to-end split for the capstone and justify it.
- Draw a sharp line between what a unit test should cover and what needs an integration test.
- Design integration tests that exercise real seams and replace external systems with fakes or contract tests.
- Wire pre-commit hooks for formatting, linting, and type checking, and explain why each gate is mandatory.
- Use coverage as a floor that prevents regressions, not as a vanity metric.
- Apply consumer-driven contract tests at external boundaries (Pact-style).
- Triage a bug into severity, impact, and root-cause tag before touching code.
- Reproduce a failure with a regression test first, then close the loop with the smallest fix.
- Diagnose a flaky test against the five most common causes and apply a targeted fix.
- Maintain a refactoring cadence (boy-scout + occasional deep) without blowing the schedule.
- Conduct a 24-hour self-review of your own code using the reviewer's rubric.
- Write technical-debt ledger entries that a future maintainer (including your future self) can act on.
Outputs
- one walking-skeleton commit in the capstone repo demonstrating a
GET /healththat returns a DB-ping result through every architectural layer - one written test plan for the capstone naming an opinionated unit / integration / end-to-end split with rationale
- one
.pre-commit-config.yaml(or language-equivalent) wired to formatter, linter, and type checker - one coverage floor configured in CI with the justification and the list of files deliberately excluded
- at least two integration tests against real seams plus one consumer-driven contract test against one external API
- one bug triage log with at least five entries tagged with Sev, impact, and root-cause category
- at least three regression tests added before the fix, each linking to the triage entry
- one flaky-test diagnosis report naming cause, diagnostic step, and fix
- one refactor journal entry naming boy-scout cleanups made in the last week and one scheduled deep refactor
- one self-review note using the reviewer's rubric applied 24 hours after writing
- one technical-debt ledger with at least five entries showing severity, owner, and why-deferred
Completion Standard
You have completed Module 2 when all of these are true:
- your capstone has a walking skeleton in the main branch and new work lives on top of it
- you can name the test split for the capstone and point at evidence of each level running in CI
- your CI blocks merges on format, lint, type, unit, and coverage-floor failures
- every bug in the last two weeks has a regression test in the repo
- you can open any flaky-test post-mortem and say which of the five common causes it was
- the code review rubric you hand yourself 24 hours later produces specific, actionable comments
- your technical-debt ledger is current, and every entry has a severity and a deferral reason
If you can ship the artifacts but cannot explain the tradeoffs, the module is not complete.
Reading Policy
- Concept pages are the main path.
- External links (Fowler's bliki, Dan North, Pact docs, Google eng-practices, flaky-test post-mortems) are small, focused, and validated.
See also (integrative)at the end of each concept page points back to prior semester modules and one outside URL. It is not required reading, it is targeted reinforcement.- In this capstone module, producing concrete artifacts in your repo is not optional enrichment. It is how the module is passed.
Suggested Weekly Flow
| Day | Work |
|---|---|
| 1 | Concepts 1-3 and the Walking Skeleton Lab: ship GET /health through every layer |
| 2 | Concepts 4-6 and the Test Strategy Workshop: commit to a split and write it down |
| 3 | Concepts 7-9 and the Quality Gates Clinic: pre-commit, lint, coverage, one contract test |
| 4 | Concepts 10-12 and two katas: one regression-first fix and one flaky-test diagnosis |
| 5 | Concepts 13-15 and two katas: one refactor under a named pattern and one ledger entry |
| 6 | Integration week: run the capstone with all gates, review the debt ledger, fix one Sev-2 |
| 7 | Quiz, self-review of last week's code, mistake-log cleanup |
Reference
If you need the cross-semester and external map, use Reference.
Rich Learning Pages
Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread