Recipe Calculator

Level: Beginner 15–30 min

Concepts: Edge CasesAlgorithms

Solutions: C# | TypeScript | Python

Implement a recipe calculator that can scale ingredients and convert between different units of measurement. The system should handle various types of ingredients and provide accurate conversions.

Requirements

  1. Scale recipes
    • Multiply or divide ingredient quantities
    • Maintain proper proportions
    • Handle fractional amounts
    • Round to appropriate precision
  2. Convert units
    • Convert between metric and imperial units
    • Handle volume and weight conversions
    • Convert between different measurement systems
    • Handle special cases (e.g., temperature)
  3. Validate inputs
    • Check for valid quantities
    • Validate unit conversions
    • Handle edge cases
    • Provide meaningful error messages

Hint

Start by implementing basic scaling and unit conversion, then add more complex features. Consider using a conversion table or matrix for unit conversions. Think about:

  • Precision and rounding rules
  • Common conversion factors
  • Input validation strategies
  • Error handling approaches
  • Zero or negative ingredient quantities
  • Rounding errors in conversions

Bonus

  • Add support for dietary restrictions
  • Implement ingredient substitution
  • Create a shopping list generator
  • Add nutritional information calculation
  • Support multiple languages and regional units

Reference Walkthrough

Reference implementations in C#, TypeScript, and Python live at tddbuddy-reference-katas/recipe-calculator. Eight scenarios cover the core scaling arithmetic: empty recipes, single- and multi-ingredient recipes, the identity factor 1, the zeroing factor 0, fractional quantities, and rejection of negative factors. The API in all three languages is the same shape: scale(recipe, factor) takes a map of ingredient name → quantity and returns a new map with every quantity multiplied by the factor. The kata’s bonus tracks (unit conversion, dietary restrictions, substitutions, shopping lists, nutrition) are out of scope — unit conversion is already demonstrated by the sibling Metric Converter kata.

This kata ships in Agent Full-Bake mode at high gear (F1 tier): the scaling arithmetic is small enough to land as one commit per language, with a brief walkthrough noting there are no builders because the inputs and outputs — an ingredient→quantity map and a numeric factor — are the domain. See the repo’s Gears section for when high gear is the right call.

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.
  • Katas Are Rehearsal, Not Performance
    You don't practice TDD on production code. You practice on katas and bring the muscle memory to production. The gap between knowing TDD and doing TDD is reps.
  • 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.