Pruebas unitarias de una regla

pytest busca archivos cuyo nombre empieza por test_ y, dentro, funciones cuyo nombre también empieza por test. Ejecuta cada una; si no salta ninguna excepción, la prueba pasa. Una comprobación se escribe con assert: si la condición es falsa, la prueba falla.

Un resultado en verde dice que los casos escritos dieron lo esperado. No dice nada de los casos que nadie escribió. Una buena lectura empieza por esa frontera: qué se comprobó y qué no.

Abre /reglas/resultado_pytest.txt y /reglas/politica.txt antes de contestar.

Una prueba sin assert pasa siempre, salvo que el código que llama lance una excepción. Llamar a la función y no mirar lo que devuelve es como comprobar que un detector de humo está enchufado sin acercarle una llama. En el informe aparece en verde y suma al número de pruebas.

Abre /reglas/test_regla_fuerza_bruta.py y revisa una por una qué comprueba cada función de prueba.

pytest solo recoge lo que sigue su convención de nombres. Una función escrita con todo el cuidado pero llamada de otra manera no falla ni avisa: simplemente no existe para el programa de pruebas. Es la forma más silenciosa de tener una cobertura menor de la que se cree.

La comparación útil es entre lo que está escrito en el archivo de pruebas y lo que pytest anuncia haber recogido: cuenta las funciones y compáralas con el número de la ejecución.

Los errores de una regla de umbral viven en el límite: «5 o más» y «más de 5» parecen lo mismo hasta que entra un usuario con exactamente el número del límite. Las buenas pruebas eligen valores justo debajo, justo en y justo encima del umbral.

Compara el criterio de la política con los casos que prueban los tres tests con eventos. Una de las cantidades que importa no se ejercita en ninguna prueba.

La prueba que falta es la del valor del límite. Si se escribe con exactamente los fallos que la política declara, y la política dice que alerta, el resultado esperado es una alerta. Esa prueba, antes de aprobar la regla, es la que dice si la regla lee lo que el equipo de seguridad escribió.

Una buena práctica es escribir el caso del límite primero y dejar que falle si el código no lo cumple: la prueba que falla por una razón correcta vale más que diez que pasan sin tocar el límite.