Inicio / Gestos cotidianos

Construir y refactorizar con los tests primero

Pide los tests antes de la implementación y lanza el runner de tests para constatar que fallan de verdad: el rojo prueba que el test puede fallar, el verde que la implementación lo satisface. Claude reproduce el estilo de los tests ya presentes en el repositorio, y el refactor avanza una preocupación a la vez.

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 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 la pregunta de si el test habría pasado incluso sin ninguna implementación.

El siguiente ejemplo usa datos propios. 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 la serie, en particular con las entradas vacías, negativas o fuera de rango que la implementación inicial suele ignorar.

Esta exigencia de prueba ejecutada ya aparecía en el test de regresión que cierra una corrección de bug, donde la confianza también viene de una salida leída.

Poner a prueba los tests con mutantes

Un test en verde prueba que el código pasa, no que el test detecte un fallo. Un mutante es un fallo inyectado a propósito en una copia del código: si la suite sigue pasando, es ciega a ese fallo. El script crea una función y su test, y luego un mutante que cambia 0.9 por 0.8.

cat > remise.js << 'EOF'
function calculerRemise(prix) { return prix * 0.9; }
module.exports = { calculerRemise };
EOF
cat > test.js << 'EOF'
const { calculerRemise } = require('./remise.js');
if (calculerRemise(200) !== 180) { console.log('ECHEC'); process.exit(1); }
console.log('OK');
EOF
node test.js
cp remise.js remise.orig.js
sed -i 's/0\.9/0.8/' remise.js
node test.js; echo "code=$?"
cp remise.orig.js remise.js
node test.js

OK
ECHEC
code=1
OK

El mutante queda eliminado, porque el test falla. Lanza primero solo el test dirigido, más rápido que la suite entera, y después la suite completa para los mutantes supervivientes únicamente. Restaura la copia original entre dos mutantes, y comprueba que el código original pasa, porque si no un fallo no prueba nada.

La no regresión se construye

Cuando una corrección cambia lo que cuenta una regla de detección, enumerar las formas que no hay que perder fracasa: un verificador siempre encuentra una más. Guarda mejor la regla antigua aparte, juzga las mismas entradas con la antigua y la nueva, y exige que toda diferencia venga de la consigna. Para un contador de palabras que pasa de separar por un espacio a separar por cualquier serie de espacios, la diferencia esperada afecta a los espacios de más, y solo a ellos.