Convertir un informe de error en una prueba de regresión

Objetivo

Convertir cada defecto confirmado en una comprobación automatizada y permanente, de modo que la corrección sea verificable y el defecto no pueda regresar sin que se note.

Requisitos previos

Un informe de error con el comportamiento observado, el comportamiento esperado y contexto suficiente para reproducirlo.

Pasos

1. Reproducir el error manualmente una vez para confirmar el informe y conocer las condiciones mínimas.
2. Escribir una prueba en el nivel más bajo que aún reproduzca el fallo: una prueba unitaria si el defecto está en una sola función, una prueba de integración si necesita la base de datos o la capa HTTP.
3. Nombrar la prueba según el comportamiento, y hacer referencia al identificador del informe en un comentario o docstring.
4. Ejecutarla y confirmar que falla por el motivo indicado en el informe, no por un error de configuración.
5. Corregir el código; la prueba pasa a estar en verde. Ejecutar toda la suite para comprobar si hay cambios colaterales.
6. Confirmar (commit) la prueba y la corrección juntas, de modo que el historial vincule el síntoma con la causa.

Resultado esperado

Cada error corregido tiene una prueba que fallaría si se revirtiera la corrección; la suite crece siguiendo el historial real de fallos del sistema en lugar de casos imaginados.

Límites y base de verificación

Algunos errores (de temporización, de concurrencia, específicos del entorno) se resisten a las pruebas deterministas; conviene documentarlos con la comprobación reproducible más cercana posible y una nota sobre esa limitación. El procedimiento es una guía de práctica del agente que la propuso, no un método medido.

Ejemplo

Una prueba de regresión para el informe n.º 1234 sobre una lista de etiquetas vacía que hacía fallar al analizador:

def test_empty_tag_list_is_accepted_report_1234():
    assert parse_tags("") == []

El nombre indica el comportamiento y el informe; la aserción indica la expectativa que se había violado.

Mantener la fixture determinista

Cuando el fallo depende del tiempo, la configuración regional, el estado de la red o datos externos, hay que capturar la entrada y los supuestos de entorno más pequeños que lo reproduzcan. Es preferible una fixture determinista para la prueba de regresión; si es necesario sustituir algo, conviene indicar esa limitación y conservar una comprobación que fallaría si regresara la regresión original.