English

Reduce tu reproducción antes de depurar

Tu depuración es lenta porque tu bucle de reproducción es lento. Arregla eso primero. Cada hipótesis que pruebas —cada print, cada breakpoint, cada "¿y si cambio esta bandera?"— corre contra tu reproducción. Si reproducir el bug toma 90 segundos y a veces ni siquiera falla, ya duplicaste en silencio el costo de cada idea que tendrás durante la próxima hora. Acelera y estabiliza el bucle antes de empezar a teorizar, y cada arreglo se lee como verdadero.

El bucle es el cuello de botella

Depurar es un bucle de hipótesis y prueba. Formas una conjetura sobre la causa, corres la reproducción, lees el resultado y ajustas. La aritmética no perdona: a 90 segundos por corrida logras unas 40 iteraciones en una hora. A 2 segundos logras cientos. El mismo cerebro, el mismo bug, 10 veces más intentos.

La intermitencia es peor que la lentitud. Una reproducción que falla el 70% de las veces convierte cada corrida en verde en ruido: no puedes distinguir "mi arreglo funcionó" de "la moneda cayó cara". Terminas volviendo a correr para ganar confianza, lo que multiplica un bucle ya de por sí lento.

Tres movimientos para un bucle rápido y determinista

1. Reduce a la entrada mínima que falla. Un bug que se reproduce en un archivo de 900 líneas, 95 acciones de usuario o una carga de producción completa es un bug que depuras entre niebla. Corta la entrada a la mitad, vuelve a correr, quédate con la mitad que sigue fallando y repite. Esto es delta debugging (Zeller, 1999): parte la entrada en dos y descarta todo lo que no sea esencial. En el caso original de Zeller, 896 líneas de HTML que hacían fallar a Mozilla se redujeron a la única línea culpable, y 95 acciones de usuario a 3.

2. Corre la única prueba que falla. Deja de correr toda la suite. La mayoría de los ejecutores tiene un camino rápido:

3. Fija semillas y relojes. El no determinismo es la razón habitual por la que una reproducción se vuelve intermitente. Elimina las dos fuentes mayores: la aleatoriedad y el tiempo. Fija cada PRNG a un valor constante y congela el reloj para que now() devuelva un valor fijo.

import random
random.seed(1337)                 # aleatoriedad reproducible

from freezegun import freeze_time
@freeze_time("2026-01-01 12:00:00")
def test_expiry():
    ...                            # cada now() queda congelado

Haz los tres y un bucle intermitente de 90 segundos se vuelve uno de 2 segundos que falla igual cada vez. Ahora una corrida en verde significa algo.

Movimientos avanzados

• Aleatoriza el orden para exponer la intermitencia, luego fija la semilla. pytest-randomly baraja el orden de las pruebas en cada corrida e imprime la semilla que usó. Cuando una corrida se vuelve intermitente, repítela con -p randomly --randomly-seed=<esa semilla> para reproducir el orden exacto. Si el bug solo aparece bajo cierto orden, tienes estado compartido entre pruebas.
• Deja que la máquina minimice por ti. Para entradas demasiado grandes para bisecar a mano, usa reductores automáticos: git bisect para encontrar el commit, C-Reduce / shrinkray para archivos de código fuente, o el reductor incorporado de una librería de property testing (Hypothesis, fast-check) que te entrega el contraejemplo mínimo gratis.
• Captura la reproducción como una prueba. Una vez que la redujiste, anótala como una prueba que falla. Marca el ritmo de esta sesión y se convierte en el guardián de regresiones que prueba el arreglo y evita que el bug regrese.

Recursos

• Delta debugging (resumen) — Wikipedia
• Zeller & Hildebrandt, "Simplifying and Isolating Failure-Inducing Input" (el algoritmo ddmin, PDF)
• pytest — detenerse tras las primeras fallas (-x, --lf)
• freezegun — congela datetime.now() en pruebas
• pytest-randomly — orden de pruebas sembrado y reproducible

<div class="cta"> <strong>¿Lanzas funciones de IA sobre un bucle lento e intermitente?</strong> Yeda AI diseña, audita y endurece sistemas LLM en producción, incluidos los arneses de pruebas que los mantienen honestos. </div>