Robot Factory
Level: Intermediate 30–60 minConcepts: Design
Solutions: C# | TypeScript | Python
This kata is about enabling a user to custom build a robot according their needs. They can configure various parts when designing the robot. The parts are provided by suppliers with whom integration is done via web services. This is because your company, believing fully in lean manufacturing, does not keep stock of any items.
Parts will be supplied by one or more suppliers at various prices; you need to make sure the customer gets the cheapest matching part.
The Robot Manufacturing Agreement of 2020 ensures parts from different suppliers are interchangeable with each other.
When building a robot, a user must configure the following parts:
| Part | Options |
|---|---|
| Head | Standard Vision, Infrared Vision, Night Vision |
| Body | Square, Round, Triangular, Rectangular |
| Arms | Hands, Pinchers, Boxing Gloves |
| Movement | Wheels, Legs, Tracks |
| Power | Solar, Rechargeable Battery, Biomass |
The user must make a selection for each part type when building the robot. You must use the parts as specified above. Not all suppliers will carry every part. You must use at least 3 parts suppliers. Do not worry about a UI - think more api integration.
There are two key methods to implement for this kata:
- Cost Robot
- Queries the various suppliers to find the lowest cost parts as specified and returns the parts with the total.
- Purchase Robot
- Purchases the parts from the respective suppliers
Hint
Use test doubles to check the behaviors you expect along the way - it helps debug the larger test.
Reference Walkthrough
Full C#, TypeScript, and Python implementations live at tddbuddy-reference-katas/robot-factory with the same twenty scenarios across all three languages, a fluent RobotOrderBuilder, a SupplierBuilder for declaring fake supplier catalogs, and domain exceptions for incomplete orders and unavailable parts.
- C# (.NET 8, xUnit, FluentAssertions) — walkthrough
- TypeScript (Node 20, Vitest, strict types) — walkthrough
- Python (3.11, pytest, dataclasses) — walkthrough
This is an Agent Full-Bake kata — one commit per language with the full domain design. The IPartSupplier interface represents the external web-service boundary; tests use in-memory fakes to verify cheapest-part selection and purchase delegation across multiple suppliers.
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. - 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. - The Hidden Output of TDD Was Never Code
The visible artifact of TDD is a passing test suite. The actual artifact, the one that compounded value over the life of the codebase, was the vocabulary the team built while writing it. The dictionary, not the regression net.