Zombie Survivor
Level: Advanced 60–90 minConcepts: StateBusiness LogicIncremental DesignEdge Cases
Solutions: C# | TypeScript | Python
Model survivors in a zombie apocalypse boardgame. This kata is structured in six steps — each step adds new rules on top of the previous ones. Resist the urge to read ahead.
Step 1: Survivors
- Each survivor has a name
- Survivors start with 0 wounds
- A survivor dies upon receiving their 2nd wound
- Additional wounds to a dead survivor are ignored
- Survivors begin with 3 actions per turn
Step 2: Equipment
- Survivors can carry up to 5 pieces of equipment
- Up to 2 pieces can be held “In Hand” — the rest go “In Reserve”
- Each wound reduces carrying capacity by 1
- When capacity decreases, excess equipment must be discarded (player’s choice)
| Wounds | Max Equipment | In Hand | In Reserve |
|---|---|---|---|
| 0 | 5 | 2 | 3 |
| 1 | 4 | 2 | 2 |
| 2 | Dead | — | — |
Step 3: The Game
- A game begins with 0 survivors
- Survivors can be added at any time
- Survivor names must be unique within a game
- The game ends when all survivors are dead
Step 4: Experience and Levels
- Survivors earn 1 experience point per zombie killed
- Four levels based on cumulative XP:
| Level | XP Required | Color |
|---|---|---|
| Blue | 0 | Starting level |
| Yellow | 7+ | |
| Orange | 19+ | |
| Red | 43+ |
- The game level equals the highest level among living survivors
Step 5: Game History
The game tracks a history log of all events:
- Game started (with timestamp)
- Survivor added
- Equipment acquired
- Wound received
- Survivor died
- Level up
- Game level changed
- Game ended
Step 6: Skills
Each survivor has a skill tree that unlocks as they level:
| Level | Skills Unlocked |
|---|---|
| Yellow | 1 skill: +1 Action (mandatory first skill) |
| Orange | Choose 1 of 2 available skills |
| Red | Choose 1 of 3 available skills |
Available skills:
- +1 Action — gain an additional action per turn
- Hoard — increase equipment capacity by 1
- Sniper — (flavor skill, no mechanical effect for this kata)
- Tough — (flavor skill, no mechanical effect for this kata)
After reaching 43+ XP, survivors restart their skill tree and can unlock additional skills at subsequent level thresholds. Maximum three complete cycles.
Test Cases
| Scenario | Expected |
|---|---|
| New survivor | 0 wounds, 3 actions, alive |
| Receive 1 wound | 1 wound, still alive, capacity 4 |
| Receive 2nd wound | Dead |
| Wound a dead survivor | No change |
| Equip 6 items | Error: max 5 |
| 1 wound with 5 items | Must discard 1 |
| Duplicate survivor name | Error: name taken |
| Kill 7 zombies | Level up to Yellow, gain +1 Action |
| All survivors dead | Game ends |
| Game level | Matches highest living survivor |
Hint
Follow the steps in order. Each step is self-contained — get it fully working and tested before moving to the next. Step 1 is trivially simple on purpose. The discipline of testing even obvious things is the point.
Reference Walkthrough
Full C#, TypeScript, and Python implementations live at tddbuddy-reference-katas/zombie-survivor with the same thirty-two scenarios across all three languages, fluent SurvivorBuilder and HistoryBuilder, domain-specific exceptions (EquipmentCapacityExceededException, DuplicateSurvivorNameException), and a Clock collaborator so history timestamps are deterministic.
- C# (.NET 8, xUnit, FluentAssertions) — walkthrough
- TypeScript (Node 20, Vitest, strict types) — walkthrough
- Python (3.11, pytest, dataclasses) — walkthrough
This kata ships in Agent Full-Bake mode (middle gear) — a single commit per language with the full domain design. See the repo’s Gears section for why that’s a deliberate teaching choice.
Related reading
- Examples Pin Intent. Properties Pin the Invariants.
Example-based tests anchor scenarios in the team's vocabulary. Property-based tests anchor invariants across the input space. The agent needs both axes, and most suites only carry one. - The Test Pyramid Was an Economic Argument
The test pyramid was not a quality law. It was a cost structure: unit tests were cheap, integration tests were expensive, so you wrote many of the first and few of the second. Agents collapsed the cost of writing tests at every level, and the cheapest test that still tells the truth is the one that pins a seam the agent cannot fake. - Agents Amplify Whatever Vocabulary They Find
Agents do not bring vocabulary to your codebase. They mirror what's already there. Strong vocabulary gets agent contributions that read like the team. Weak vocabulary gets faster mediocrity. The work you did for craft reasons just became leverage.