Skip to main content

Walking Skeleton Lab

Deliverable: one commit in the capstone repo that is a walking skeleton -- an end-to-end request that crosses every layer, runs in CI, and deploys to staging.

Retrieval Prompts​

  1. State the three words in "walking skeleton" and what each one requires.
  2. Explain the difference between a walking skeleton, a steel thread, and a minimum viable product.
  3. Name the minimum set of layers your capstone's walking skeleton must traverse.
  4. State the single most important property a walking skeleton must preserve as features are added.

Compare and Distinguish​

Separate these pairs clearly:

  • walking skeleton versus minimum viable product
  • walking skeleton versus steel thread (which one proves what?)
  • vertical slice versus horizontal layer
  • integration test against real DB versus unit test against mocked DB

Common Mistake Check​

For each statement, identify the error:

  1. "The skeleton uses an in-memory stub for the DB because the real DB is not set up yet."
  2. "The skeleton is throwaway code; the real version will replace it later."
  3. "We can skip deploying the skeleton because it runs locally."
  4. "The walking skeleton's endpoint must do something useful for a user."

Mini Application​

In one session (90 minutes):

  1. Decide the single request the skeleton will answer. Default recommendation: GET /health returning a DB ping.
  2. List every layer it must traverse in your capstone architecture. Include transport, framework, domain, data access, database, deploy target, observability hooks.
  3. Write the smallest implementation of each layer that participates.
  4. Write one test that exercises the request end-to-end against a real database.
  5. Wire that test into CI so every PR runs it.
  6. Deploy the skeleton to a staging environment (local container counts on day 1; staging by day 3).
  7. Record evidence: the passing CI run link, and the staging URL returning 200.

Evidence Check​

This lab is complete only when:

  • a reviewer can clone your repo, run one command, and see the skeleton pass
  • a CI run shows the skeleton test green on the main branch
  • you can point at the request in staging and see a response
  • the skeleton's response crosses all your architectural layers, not a subset

Stretch​

  • Add a single structured log line from the skeleton (trace/span/level) so Module 4 observability has something to bind to.
  • Add the skeleton's request as a contract test (see Concept 9) to pin its shape early.