English

Nunca desactives los warnings en Pytest

Silenciaste el warning que predijo tu caída en producción. Es una jugada común: la corrida de tests se pone ruidosa, alguien (o algún agente de IA) agrega --disable-warnings o -p no:warnings a la configuración, y la salida queda limpia. Los warnings no desaparecieron — solo dejaste de enterarte.

Por qué pytest muestra warnings

Python por sí solo ignora DeprecationWarning por defecto, salvo que el código que lo dispara viva en __main__: los autores de librerías te avisan y el intérprete se lo traga. Pytest invierte esto a propósito: desde la versión 3.1 captura los warnings durante la ejecución de los tests e imprime un resumen al final de la sesión, incluyendo DeprecationWarning y PendingDeprecationWarning de tu código y de las librerías que usas.

Eso no es ruido. Es el único lugar de tu flujo de trabajo donde las deprecaciones tienen garantía de aparecer. Un deprecation warning es el autor de una librería diciéndote, un release antes, exactamente cuál de tus llamadas se va a romper en la próxima actualización. Silencia el canal y la primera noticia será un stack trace — quizá en producción, quizá durante una actualización de seguridad urgente que no puedes postergar.

Los interruptores generales — y lo que hacen en realidad

Esto importa el doble cuando un agente de IA mantiene tu configuración. "Haz que los tests pasen limpios" es exactamente el tipo de instrucción que tienta a un agente a agregar una supresión general: cumple el pedido y esconde el costo. Revisa cualquier diff que toque filterwarnings, addopts o plugins de warnings como cualquier otro cambio de producción.

Filtra con bisturí, no con interruptor

La opción ini filterwarnings de pytest usa la misma gramática de filtros que el módulo warnings de Python, y cuando un warning coincide con varias líneas, gana la última coincidencia. Ese orden es todo el truco: empieza estricto y luego talla solo las excepciones que ya evaluaste:

[pytest]
filterwarnings =
    error
    ignore::UserWarning
    ignore:function ham\(\) is deprecated:DeprecationWarning

La línea 1 promueve cada warning a error, así las deprecaciones nuevas rompen el build el día que aparecen. Las líneas 2–3 son excepciones deliberadas y revisables: una categoría específica, o un regex de mensaje concreto de una dependencia contra la que ya abriste un issue. Cada línea ignore en la configuración es una decisión documentada, no un encogimiento de hombros.

Para una excepción de un solo test, acota aún más el alcance con el mark: @pytest.mark.filterwarnings("ignore:api v1:DeprecationWarning").

Jugadas avanzadas

• Convierte el warning en aserción. Cuando tu propio código depreca algo, prueba la deprecación misma con pytest.warns(DeprecationWarning): el warning pasa a ser un contrato, no basura visual.
• Distingue las flags. -W / --pythonwarnings en la CLI compara los mensajes de forma literal, mientras que la opción ini filterwarnings los trata como patrones regex. Copiar y pegar entre ambas cambia en silencio qué se filtra.
• Ajusta gradual, no de golpe. En una suite legada, error desde el día uno puede significar cientos de fallas. Agrega error, luego ignore temporal para los ofensores actuales como líneas explícitas, y borra una línea por semana. La lista solo se achica.
• Presupuesta el ruido. Si una corrida imprime 300 warnings, cuenta las fuentes distintas: suelen ser 3–5 tareas de actualización, no 300 problemas.

Recursos

• How to capture warnings — documentación de pytest
• Opción ini filterwarnings — referencia de pytest
• pytest.mark.filterwarnings — referencia de pytest
• pytest.warns — referencia de pytest
• El módulo warnings — documentación de Python