Qué hacían los fixtures
Los fixtures de test destruían su contenedor con docker rm -f. Según la descripción del propio test de regresión, docker run crea un volumen anónimo por contenedor, y rm -f sin -v lo deja atrás. No falla nada: el contenedor desaparece, el test sale en verde y el volumen se queda en disco.
La documentación oficial describe el flag que cierra el hueco: -v, –volumes significa “Remove anonymous volumes associated with the container” (elimina los volúmenes anónimos asociados al contenedor).
Qué dice el mensaje del commit
El mensaje del commit del cambio cuantifica la fuga durante un día de ejecuciones de test. No repito sus cifras aquí: el repositorio guarda el mensaje, no una medición capturada, así que el artículo se limita a lo que muestra el código. El mismo mensaje dice que el cambio es solo de tests, sin tocar código de producción ni de operaciones.
El cambio
Los fixtures ahora eliminan el contenedor junto con sus volúmenes anónimos mediante un helper compartido en el conftest de la suite de voz. Un test estructural comprueba que el finalizador de limpieza se registra antes de ejecutar docker network create, de modo que un fallo a mitad del setup también limpia.
El test de regresión
El test de regresión arranca un contenedor desechable con la misma imagen que usan los fixtures y comprueba únicamente los nombres de volumen de ese contenedor, nunca el recuento global de volúmenes del host. Su control negativo reproduce el desmontaje antiguo: elimina un contenedor con docker rm -f y comprueba que el volumen sigue existiendo. Un segundo contenedor pasa por el helper, y el test comprueba que su volumen desaparece mientras el del primero queda intacto.
Un guardia estructural falla si un fichero de fixtures conserva la línea docker rm -f sin más. El mensaje del commit añade que el test se comprobó por mutación: reintroducir cualquiera de los dos defectos lo hace fallar.
La lección
La limpieza de infraestructura efímera de test necesita dos cosas: eliminar el contenedor con sus volúmenes anónimos, y registrar esa limpieza antes de crear los recursos. Después, escribe el test de regresión con un control negativo, para que falle si el defecto vuelve.
Busca docker rm -f sin -v en el teardown de tus fixtures de Postgres.
