TCR (Test && Commit || Revert)

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

TCR significa Test && Commit || Revert. Su presión de feedback favorece incrementos muy pequeños; requiere una suite estable y un punto de restauración claramente definido.

Ejemplo de uso

Secuencia conceptual: guardar el estado inicial, editar una sola regla, ejecutar pruebas; si pasan, registrar el cambio; si fallan, restaurar únicamente ese intento. Repetir con un paso menor.

Script seguro

#!/usr/bin/env sh
# tcr.sh: ejecutar en una rama o worktree dedicado
set -u

if ! ./mvnw -q compile test-compile; then
  echo "No compila: corrige antes de probar (no se revierte)"; exit 1    # variante BTCR
fi

if ./mvnw -q test; then
  git add -A && git commit -q -m "tcr: $(date +%H:%M:%S)" && echo "✔ commit"
else
  git restore --staged --worktree -- src/main     # revierte solo código de producción
  git clean -fdq -- src/main
  echo "✘ revertido: da un paso más pequeño"
fi

Revertir solo src/main y no las pruebas (relaxed TCR) permite conservar la prueba nueva que estabas intentando hacer pasar. Evita git reset --hard sobre todo el repositorio: borraría también cambios no relacionados.

Variantes

Variante	Regla
TCR estricto	Cualquier fallo revierte todo el cambio
BTCR	Si no compila, no revierte (el error es evidente); si fallan pruebas, sí
Relaxed TCR	Revierte el código de producción y conserva las pruebas
Con watcher	El script se ejecuta automáticamente al guardar
Limbo	Variante colaborativa: los commits se integran y sincronizan continuamente entre varias personas

Qué enseña

• A dividir los cambios en pasos de minutos: si pierdes el trabajo por un fallo, aprendes a dar pasos más pequeños.
• A refactorizar con seguridad: cada estado intermedio compila y pasa las pruebas.
• A tener una suite rápida: si tarda un minuto, TCR se vuelve insoportable y muestra el problema.

Cómo introducirlo en un equipo

Úsalo primero en katas o coding dojos (por ejemplo, la kata del cálculo de cuotas) y en sesiones de pairing (Tuple). En el trabajo real, aplícalo a refactorizaciones con buena cobertura. Antes de abrir el PR, agrupa los micro-commits con un squash para mantener un historial legible.

Con agentes de código

TCR es un buen modo de trabajo para un agente: cada paso verificado se conserva y los intentos fallidos desaparecen en lugar de acumular cambios rotos. Combínalo con feedback sensors y protege los archivos de prueba para que el agente no «arregle» las pruebas en vez del código.

Criterios de implementación

Distinguir un fallo de pruebas de un fallo al crear el commit. Evitar scripts que borren cambios ajenos o reviertan por errores de Git; practicar primero en una rama o worktree desechable.