Parking Lot
Level: Intermediate 30–60 minConcepts: DesignState
Solutions: C# | TypeScript | Python
Create a program to manage a parking lot system with different types of vehicles and parking spots.
Requirements
- Implement parking lot management:
- Different types of vehicles (Motorcycle, Car, Bus)
- Different types of parking spots (Motorcycle, Compact, Large)
- Parking rules based on vehicle and spot types
- Track available spots and parked vehicles
- Handle parking operations:
- Park a vehicle (assign to appropriate spot)
- Remove a vehicle (free up spot)
- Check parking status
- Find available spots
- Return appropriate results:
- Success/failure of parking operations
- Current parking lot status
- Error messages for invalid operations
Test Cases
| Scenario | Input | Expected Result | Notes |
|---|---|---|---|
| Empty Lot | Check status | All spots available | Initial state |
| Park Motorcycle | Park motorcycle in motorcycle spot | Success | Fits in any spot |
| Park Car | Park car in compact spot | Success | Fits in compact or large |
| Park Bus | Park bus in large spot | Success | Needs 5 consecutive large spots |
| Invalid Park | Park car in motorcycle spot | Error | Spot too small |
| Remove Vehicle | Remove parked vehicle | Success | Frees up spot |
Edge Cases to Consider
- Parking lot is full
- Vehicle already parked
- Removing non-existent vehicle
- Parking in occupied spot
- Multiple vehicles of same type
Tips
- Start with basic vehicle and spot types
- Add parking rules next
- Then implement spot management
- Finally add status tracking
- Consider using enums for vehicle and spot types
Reference Walkthrough
Full C#, TypeScript, and Python implementations live at tddbuddy-reference-katas/parking-lot. Twenty-two scenarios across lot construction, spot allocation (smallest-fit-first), entry with duplicate detection, exit with ticket validation, time-based fee calculation (per-hour rates by vehicle type, partial-hour ceiling, minimum one-hour charge), and an end-to-end worked example — shared across all three languages — with a Lot aggregate, Vehicle / Ticket / Fee value types, VehicleType and SpotType enums, Clock collaborator, LotBuilder + VehicleBuilder + FixedClock test doubles, and four domain exception types (VehicleAlreadyParkedException, NoAvailableSpotException, InvalidTicketException, InvalidLotConfigurationException).
- C# (.NET 8, xUnit, FluentAssertions) — walkthrough
- TypeScript (Node 20, Vitest, strict types) — walkthrough
- Python (3.11, pytest, frozen dataclasses, Protocol clock) — walkthrough
This kata ships in Agent Full-Bake (F3) mode: one commit per language with the full domain design landing together. The walkthroughs read as design rationale — why smallest-fit-first allocation preserves large spots for buses, why Fee is a value type not a bare decimal, why Clock is injected (same pattern as rate-limiter and memory-cache).
The reference simplifies the spec’s “bus needs 5 consecutive large spots” to “bus needs one large spot” — each spot is atomic, and the teaching focus is on allocation strategy and fee calculation rather than consecutive-spot search algorithms. The bonus items (floors/zones, dynamic pricing, reservation systems) are deliberately out of scope — the SpotType enum and Lot aggregate are ready to grow without the reference hiding seams under premature abstraction. See the repo’s Gears section for when middle gear is the right call.
Related reading
- 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. - Test Deletion Is a Privileged Operation
The cheapest way for an agent to make a failing test pass is to delete it. That is logical for the agent and catastrophic for the codebase. Tests are append-only by default. Deletion needs a human author, a separate commit, and a separate review. - The Instruction File Is Not the Discipline
Teams that want their agent to do TDD reach for the instruction file. The TDAD paper measured this directly: adding a 'do TDD' instruction raised regressions by nearly two-thirds. Contextual test discovery cut them by seventy percent. The instruction is theatre. The codebase's test surface is the discipline.