Test Driven Development with Claude

In this lesson you’ll see a practical TDD (Test-Driven Development) workflow accelerated by an LLM-based code assistant. We generate a full pytest test suite for a small Python “Unit Converter” utility, run the tests (red), implement the module to satisfy them (green), and handle a real-world precision edge case that required human judgment.

Why this matters: TDD is powerful when applied consistently. LLM-based assistants speed up the specification and test generation steps, but you still need to run tests, inspect failures, and make precise human decisions for numerical correctness and edge cases. Overview

Create a small Python project: a Unit Converter module.
Use an LLM-based code assistant to produce a robust pytest suite (test_converter.py).
Run tests (expected to fail initially because converter.py is missing).
Implement converter.py to satisfy tests.
Iterate until all tests pass; investigate any precision failures and decide whether to change constants, test tolerances, or implementation rounding.

Initial project state

Virtual environment active (Python 3).
File test_converter.py created by an LLM from a detailed prompt (implementation intentionally omitted).

Example prompt used to generate tests (trimmed)

You are an expert Python developer practicing test-driven development.
Your first task is to write a complete and robust pytest test suite for a new module, converter.py.
Do not write the implementation code for the functions. Your sole responsibility is to generate pytest tests.

Project: Unit Converter Module

Functional Requirements:
- Each function accepts a single numeric argument (int or float) and returns a float.

Distance Conversions:
  - miles_to_kilometers(miles) — 1 mile = 1.60934 kilometers
  - kilometers_to_miles(km) — 1 kilometer = 0.621371 miles

Volume Conversions:
  - gallons_to_liters(gallons) — US gallon to liters
  - liters_to_gallons(liters) — liters to US gallons

Mass Conversions:
  - pounds_to_kilograms(pounds)
  - kilograms_to_pounds(kg)

Temperature Conversions:
  - fahrenheit_to_celsius(fahrenheit)
  - celsius_to_fahrenheit(celsius)

Test expectations:
- Correctness tests with integer and floating inputs.
- Edge cases: 0 and negative numbers.
- Error handling: non-numeric input should raise TypeError (use pytest.raises).
- Use pytest.approx() where appropriate for floating point comparisons.

What the generated tests looked like (structure, trimmed)

# test_converter.py
import pytest
from converter import (
    miles_to_kilometers,
    kilometers_to_miles,
    gallons_to_liters,
    liters_to_gallons,
    pounds_to_kilograms,
    kilograms_to_pounds,
    fahrenheit_to_celsius,
    celsius_to_fahrenheit
)

class TestDistanceConversions:
    def test_miles_to_kilometers_positive_integer(self):
        assert miles_to_kilometers(1) == pytest.approx(1.60934)
        assert miles_to_kilometers(5) == pytest.approx(8.0467)

    def test_miles_to_kilometers_float(self):
        assert miles_to_kilometers(2.5) == pytest.approx(4.02335)

    def test_miles_to_kilometers_zero(self):
        assert miles_to_kilometers(0) == pytest.approx(0.0)

    def test_miles_to_kilometers_negative(self):
        assert miles_to_kilometers(-3) == pytest.approx(-4.82802)

    def test_miles_to_kilometers_type_error(self):
        with pytest.raises(TypeError):
            miles_to_kilometers("test")
# ... similar classes for volume, mass, temperature

Running the tests before implementation

With only test_converter.py present (no converter.py), pytest fails at collection:

==================================== ERRORS ====================================
ERROR collecting test_converter.py
ImportError while importing test module '.../test_converter.py'.
E   ModuleNotFoundError: No module named 'converter'
============================= short test summary info =============================
ERROR test_converter.py
============================= 1 error in 0.07s

This is the expected TDD “red” phase: tests fail because the implementation is missing. Implementing converter.py Requirements for each function:

Validate input is numeric (int or float). If not, raise TypeError.
Return the converted value as a float.
Prefer well-known constants for conversions to avoid unnecessary precision disagreements.

Reference table of functions and conversion constants

Function	Purpose	Recommended constant / note
`miles_to_kilometers(miles)`	Miles → Kilometers	Multiply by `1.60934`
`kilometers_to_miles(km)`	Kilometers → Miles	Multiply by `0.621371`
`gallons_to_liters(gallons)`	US Gallons → Liters	Multiply by `3.785411784`
`liters_to_gallons(liters)`	Liters → US Gallons	Multiply by `0.2641720523581484`
`pounds_to_kilograms(pounds)`	Pounds → Kilograms	Multiply by `0.45359237`
`kilograms_to_pounds(kg)`	Kilograms → Pounds	Multiply by `2.2046226218487757`
`fahrenheit_to_celsius(fahrenheit)`	°F → °C	`(fahrenheit - 32) * 5.0 / 9.0`
`celsius_to_fahrenheit(celsius)`	°C → °F	`celsius * 9.0 / 5.0 + 32`

Recommended implementation (clean, precise)

def _validate_numeric(value, name="Input"):
    if not isinstance(value, (int, float)):
        raise TypeError(f"{name} was not a numeric value")


def miles_to_kilometers(miles):
    """Converts miles to kilometers."""
    _validate_numeric(miles, "miles")
    return miles * 1.60934


def kilometers_to_miles(km):
    """Converts kilometers to miles."""
    _validate_numeric(km, "km")
    return km * 0.621371


def gallons_to_liters(gallons):
    """Converts US gallons to liters."""
    _validate_numeric(gallons, "gallons")
    # 1 US gallon = 3.785411784 liters (exact)
    return gallons * 3.785411784


def liters_to_gallons(liters):
    """Converts liters to US gallons."""
    _validate_numeric(liters, "liters")
    # reciprocal of 3.785411784
    return liters * 0.2641720523581484


def pounds_to_kilograms(pounds):
    """Converts pounds to kilograms."""
    _validate_numeric(pounds, "pounds")
    # 1 pound = 0.45359237 kilograms (exact)
    return pounds * 0.45359237


def kilograms_to_pounds(kg):
    """Converts kilograms to pounds."""
    _validate_numeric(kg, "kg")
    # reciprocal of 0.45359237
    return kg * 2.2046226218487757


def fahrenheit_to_celsius(fahrenheit):
    """Converts degrees Fahrenheit to Celsius."""
    _validate_numeric(fahrenheit, "fahrenheit")
    return (fahrenheit - 32) * 5.0 / 9.0


def celsius_to_fahrenheit(celsius):
    """Converts degrees Celsius to Fahrenheit."""
    _validate_numeric(celsius, "celsius")
    return celsius * 9.0 / 5.0 + 32

Running pytest after implementation

After implementing converter.py, run:

python3 -m pytest -v

In the demo workflow this produced 39 passing tests and 1 failure. The failing test revealed a small precision mismatch in the gallons-to-liters expectation:

collected 40 items
.......................................F
================================== FAILURES ==================================
________________ TestVolumeConversions.test_gallons_to_liters_float ________________
E       comparison failed
E       Obtained: 10.4098775
E       Expected: 10.409778 ± 1.0e-05

1 failed, 39 passed in 0.05s

Precision and the LLM “endless edit” loop

LLMs are excellent at producing tests and starter code, but they can trigger small regression cycles: you tweak a constant or rounding to satisfy one test and then break another test. These oscillations require human decisions:
- Should the implementation use a specific authoritative constant?
- Is the test tolerance too strict (adjust pytest.approx)?
- Is rounding required for business logic?

Note: numerical conversions depend on chosen constants and tolerances. Prefer matching documented constants and using pytest.approx() in tests with a reasonable tolerance. Avoid introducing ad-hoc conditional logic in the implementation to satisfy a single test.

Recommendations and practical workflow tips

Use an LLM-based assistant to accelerate test generation from a clear, precise prompt.
Run tests locally as part of the TDD loop: write (or generate) tests, run them, implement the minimal code to pass, iterate.
For floating point comparisons:
- Use authoritative physical constants where available.
- Use pytest.approx() with an appropriate tolerance rather than tight equality.
- If a business requirement dictates strict rounding, document it and implement rounding explicitly.
Expect to intervene when the LLM’s automated edits produce regressions—this is part of normal engineering judgment.

Conclusion

LLM-based tools are powerful for generating tests and scaffolding implementations, but treat their output as a solid starting point, not a final answer.
Follow core TDD steps:
1. Write/generate tests first.
2. Run tests and see failures.
3. Implement minimally to satisfy tests.
4. Iterate until passing, paying attention to numerical precision and test quality.
Human review is essential for precision, edge cases, and architectural choices.

Links and references

pytest documentation: https://docs.pytest.org/en/stable/
Python packaging and virtual environments: https://packaging.python.org/
Conversion constants reference (examples): NIST or other authoritative sources

Introduction

Getting Started with Claude Code

Working with Claude Code

Code Review with Claude Code

Security Auditing with Claude Code

Advanced Features

Test Driven Development with Claude

Watch Video