Inicio / Gestos cotidianos

Construir y refactorizar con los tests primero

Claude Code examina los archivos de test ya presentes en un proyecto para escribir un nuevo test con el mismo estilo antes de la implementación, y confirmar que ese test falla realmente prueba que efectivamente está probando algo que todavía no existe.

Claude examina los archivos de test ya presentes en un repositorio para reproducir su estilo, su framework de test y sus convenciones de aserción, en lugar de imponer una convención ajena al proyecto. El gesto consiste en pedir esos tests antes de escribir la implementación que deben verificar, y luego lanzar el runner de tests para constatar que efectivamente fallan.

Confirmar el rojo antes de pedir el verde

Esta secuencia, conocida en ingeniería de software como rojo, verde, refactor, no depende de ninguna funcionalidad específica de Claude Code, sigue siendo válida con cualquier herramienta. El rojo prueba que el test puede fallar, el verde prueba que la implementación lo satisface, y saltar directamente al verde sin haber visto el rojo deja abierta una pregunta incómoda: la de saber si el test habría pasado incluso sin ninguna implementación.

El siguiente ejemplo fabrica sus propios datos para seguir siendo válido en cualquier lectura. Un test espera que una función calculerRemise aplique un diez por ciento de descuento, incluso antes de que esa función exista.

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

testCalculerRemise();
// ReferenceError: calculerRemise is not defined, el rojo esperado

Una vez constatado ese rojo, la implementación mínima basta para hacerlo pasar a verde.

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

testCalculerRemise();
// ninguna salida: la aserción es verdadera, el test está en verde

Refactorizar una preocupación a la vez

El runner de tests permanece activo durante todo el refactor que sigue, y cada modificación se centra en una sola preocupación, un solo nombre renombrado, una sola función extraída, nunca varias a la vez en el mismo turno. Esta disciplina aísla la regresión: si el runner de tests falla después de un cambio, la causa está en ese cambio concreto, no en un conjunto de modificaciones apiladas que habría que desenredar. Pedirle explícitamente a Claude que identifique los casos límite no cubiertos antes de considerar terminada una serie de tests completa el cuadro, en particular sobre las entradas vacías, negativas o fuera de rango que la implementación inicial suele ignorar.

Esta exigencia de prueba ejecutada enlaza con el test de regresión que cierra una corrección de bug: en ambos casos, la confianza viene de una salida leída, no de una lectura del código.