Pruebas unitarias que fallan si se rompe la autorización

Las decisiones de permiso se prueban mejor donde se toman: en la función o la clase de política que responde «sí» o «no», sin levantar la aplicación entera. Ahí una prueba es barata, corre en cada cambio y puede recorrer los casos que importan. Pero una prueba de autorización solo sirve si fallaría al romperse la regla. Eso exige tres cosas: casos que deben responder «no» (los permisos de más son el fallo típico y nadie se queja de ellos), casos en el borde de cada condición (el límite exacto, el otro inquilino, el factor que falta) y llamar a la política de verdad, no a una sustituta.

La cobertura de líneas no mide nada de eso: una línea con tres condiciones queda «cubierta» con un solo caso que las cumple todas. Las pruebas de mutantes sí lo miden. La herramienta hace copias del código con un cambio pequeño cada una (borra una condición, cambia <= por <, devuelve True) y corre las pruebas contra cada copia. Si alguna falla, el mutante queda muerto; si todas pasan, sobrevive, y un mutante que sobrevive es un cambio que nadie notaría.

Abre el laboratorio y lee test_api_estado_cuenta.py y luego conftest.py. Las dos pruebas del controlador piden el estado de cuenta de una unidad con dos residentes distintos, pero ninguna de las dos puede fallar por un permiso: una usa un accesorio que cambia la decisión real por una que siempre dice que sí, y la otra acepta cualquiera de los dos códigos.

Sustituir dependencias está bien para aislar una prueba; sustituir justo lo que la prueba dice comprobar la deja vacía.

Lee informe-mutantes.txt junto con politicas.py. Cada mutante dice la línea y el cambio. La plataforma es multiinquilino: la administración de un conjunto no debe ver nada de otro. Busca el mutante sobreviviente que quita justo esa frontera en el estado de cuenta, y comprueba en test_politicas.py que ninguna prueba usa una administración de otro conjunto.

No todos los sobrevivientes pesan igual. Unos abren un permiso que hoy se niega (quitar una condición siempre abre). Otros cierran uno que hoy se concede: es un fallo funcional, también hay que probarlo, pero no deja entrar a nadie. Y hay mutantes equivalentes, que cambian el código sin cambiar ninguna respuesta posible y no se pueden matar con ninguna prueba. Lee las notas del equipo para saber qué pasa en el límite del gasto.

Cada sobreviviente se mata con un caso concreto. Para el de la verificación reciente del segundo factor, piensa qué valores tiene que tener la persona de la prueba para que la única diferencia entre permitir y negar sea esa condición.