Robot Factory

Level: Intermediate 30–60 min

Concepts: 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.

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.
  • 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.