Home / Everyday moves

Building and refactoring with tests first

Claude Code examines the test files already present in a project to write a new test in the same style before the implementation, and confirming that this test genuinely fails proves it does indeed test something that does not exist yet.

Claude examines the test files already present in a repository to reproduce their style, their test framework, and their assertion conventions, rather than imposing a convention foreign to the project. The gesture consists of requesting these tests before writing the implementation they are meant to verify, then running the test runner to confirm they genuinely fail.

Confirm red before asking for green

This sequence, known in software engineering as red, green, refactor, does not depend on any Claude Code specific feature, it remains valid with any tool. Red proves that the test can fail, green proves that the implementation satisfies it, and jumping straight to green without having seen red leaves an awkward question open: whether the test would have passed even without any implementation at all.

The following example fabricates its own data to stay valid for any reader. A test expects a calculerRemise function to apply a ten percent discount, before this function even exists.

function testCalculerRemise() {
  const resultat = calculerRemise(200);
  console.assert(resultat === 180, "attendu 180, obtenu " + resultat);
}

testCalculerRemise();
// ReferenceError: calculerRemise is not defined, le rouge attendu

Once this red is observed, the minimal implementation is enough to turn it green.

function calculerRemise(prix) {
  return prix * 0.9;
}

testCalculerRemise();
// aucune sortie : l'assertion est vraie, le test est au vert

Refactoring one concern at a time

The test runner stays active throughout the refactor that follows, and each change touches a single concern, one name renamed, one function extracted, never several at once in the same turn. This discipline isolates the regression: if the test runner fails after a change, the cause lies in that precise change, not in a stack of piled up modifications that would need to be untangled. Explicitly asking Claude to identify uncovered edge cases before considering a set of tests complete rounds out the picture, particularly for empty, negative, or out of range inputs that the initial implementation often ignores.

This requirement for executed proof echoes the regression test that closes a bug fix: in both cases, confidence comes from an output that was read, not from a reading of the code.