Convertir un error en una prueba de regresión

Objetivo

Cada error confirmado deja una comprobación automática y permanente que respalda la corrección y vuelve a poner el error de inmediato en evidencia si un cambio posterior lo reintroduce.

Requisitos previos

Un informe de error con pasos reproducibles, el resultado esperado y el resultado real; una suite de pruebas que se ejecute tanto en local como en la CI.

Pasos

1. Reproducir el error una vez a mano para confirmar el informe y averiguar las condiciones mínimas: ¿qué entrada, qué estado, qué orden?
2. Elegir el nivel más bajo en el que el error todavía se manifiesta: una prueba unitaria si una función calcula mal; una prueba de integración si hace falta la base de datos o la capa HTTP. Cuanto más bajo el nivel, más rápida y estable es la prueba.
3. Nombrar la prueba según el comportamiento y anotar el número del informe en el docstring o en un comentario: test_export_akzeptiert_umlaute_im_dateinamen, con referencia al ticket.
4. Ejecutar la prueba y comprobar que falla por el motivo reportado, y no por una errata en la prueba o por la falta de datos de prueba. Una prueba que nunca ha estado en rojo no demuestra nada.
5. Corregir hasta que la prueba pase a verde; mientras tanto, repetir solo esa prueba (en pytest, --lf o --last-failed vuelve a ejecutar las pruebas que fallaron en la última ejecución) y, después, ejecutar toda la suite para descartar efectos secundarios.
6. Guardar la prueba y la corrección en el mismo commit, con una referencia al informe; así el historial une el síntoma con la causa, y un git bisect posterior encuentra ambos.
7. Si la corrección se aplaza: subir la prueba de todos modos y marcarla con @pytest.mark.xfail(strict=True, reason="Ticket 4711"). Se ejecuta con el resto y se considera un fallo esperado; en cuanto pasa de forma inesperada (XPASS), la suite da la alarma: el error ha desaparecido sin que nadie lo notara y el ticket merece una revisión.

Resultado esperado

La suite de pruebas crece siguiendo el historial real de errores del sistema y no casos imaginados; si se revierte una corrección, la CI lo detecta y no la clienta.

Límites y base de verificación

Los errores de tiempo, de carga y de concurrencia a menudo no se pueden reproducir de forma determinista; en ese caso se escribe la mejor comprobación reproducible disponible y se anota la laguna en el informe. Una prueba de regresión inestable (flaky) no se silencia con reintentos: se repara o se aparca como xfail con una justificación. Las opciones de pytest siguen la documentación citada; el procedimiento en sí es una recomendación práctica sin mediciones.