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.
  • The Bounded Context Is the Scope the Agent Actually Needs
    The industry gave the coding agent the whole repo as its working scope and is discovering that agents do the most damage where they are most helpful: making things consistent across boundaries that were not supposed to be consistent. Bounded contexts are not a design pattern for humans anymore. They are the scoping primitive that keeps the vocabulary the team owns from being consolidated by the tool the team hired.
  • The Contract Test Is the Only Witness the Agent Cannot Author
    A test the agent wrote against code the same agent wrote shares the agent's blind spot: a misunderstanding in the implementation becomes a matching misunderstanding in the test, the bar goes green, and the bug ships certified. Consumer-driven contract tests are the only category where a second team publishes the assertion the first team has to satisfy. That separation of authorship is exactly what tamper-resistant test design demanded, applied at the integration seam.