Pruebas escritas dentro de la colección

En Postman, el script de la pestaña de pruebas se ejecuta después de recibir la respuesta. Cada comprobación se nombra con pm.test y su criterio se escribe con pm.expect o con pm.response.to. Bruno tiene la misma idea con su propia sintaxis: test y expect, escritos en el archivo de la petición. En los dos casos el resultado de cada prueba es superada o fallida.

Lo importante para quien evalúa es qué significa una prueba superada: significa que se cumplió el criterio que alguien escribió, ni más ni menos. Si el criterio es débil, o está al revés, la prueba se supera y no dice nada del servidor.

Hay criterios que no dependen de la respuesta. Un expect que compara un valor con él mismo se supera siempre, llegue lo que llegue del servidor. Suele quedar así cuando alguien escribe el esqueleto de una prueba para rellenarlo luego y no vuelve. En una auditoría de colecciones esas pruebas son ruido peligroso: suman a la cifra de superadas y no verifican nada.

Abre scripts_de_prueba y lee la columna script_de_prueba. Busca la petición cuyo criterio no mira la respuesta.

Una petición sin script envía y recibe, pero nadie comprueba la respuesta: en un informe de ejecución aparece como enviada, no como verificada. No es un fallo de la herramienta, es un hueco de la colección. Cuando se cuenta cuánto cubre una colección, las peticiones sin pruebas se anotan aparte.

Comprobar el código de estado es la prueba más básica: dice que el servidor respondió como el contrato esperaba, pero no dice nada del contenido. Para el informe interesa cuántas peticiones tienen al menos una prueba de ese tipo, porque define el suelo de la cobertura. En Postman se reconoce porque el script contiene have.status.

La petición obtenerPedidoAjeno corre con la cuenta cliente_a y pide un pedido cuyo dueño es otra cuenta, según objetos_de_prueba. Su script espera un código 200. Si la prueba se supera, el servidor entregó a una cuenta un objeto que no era suyo: la prueba pasa y es justo el problema.

Un criterio de autorización se escribe esperando el rechazo. Con el criterio correcto, la prueba falla contra este servidor, y ese fallo es lo que se documenta.