Lección 4 de 6 · 2 min
Tests y aserciones automáticas
Al terminar sabrás
11 min- Escribir aserciones con pm.test y pm.expect para validar status, body y tiempo
- Validar la estructura del JSON, no solo que responda 200
- Probar los casos negativos: qué debe pasar cuando el request es inválido
Construyes: Un request con 4 aserciones automáticas (status, esquema, valor y tiempo) que pasa o falla solo.
De "mirar la respuesta" a "que la valide sola"
Hasta ahora enviabas el request y revisabas la respuesta con el ojo. Eso no escala ni se automatiza. La magia de Postman es la pestaña Tests: código JavaScript que corre después de cada respuesta y asegura que todo esté como debe. Cada prueba aparece en verde (pasó) o rojo (falló).
Las aserciones básicas
// Pestaña "Tests"
pm.test("El status es 200", () => {
pm.response.to.have.status(200);
});
pm.test("Responde en menos de 800 ms", () => {
pm.expect(pm.response.responseTime).to.be.below(800);
});
pm.test("nombre", fn) define una prueba; dentro, pm.expect(...) expresa la expectativa. El nombre importa: "trae el id de la reserva" en rojo se explica solo.
No basta con el status: valida la estructura
El error de novato es asertar solo status 200 y darse por satisfecho. Un 200 puede traer un body incompleto o con el dato equivocado:
pm.test("La respuesta trae los campos esperados", () => {
const json = pm.response.json();
pm.expect(json).to.have.property("id");
pm.expect(json).to.have.property("servicio");
pm.expect(json.id).to.be.a("number");
});
Los casos negativos: donde viven los bugs
La UI valida antes de enviar, pero ¿y si alguien llama a la API directo? Ahí están los bugs vergonzosos:
// Request: POST sin el campo obligatorio "telefono"
pm.test("Rechaza el pedido inválido con 400", () => {
pm.response.to.have.status(400);
});
pm.test("El mensaje de error explica qué falta", () => {
pm.expect(pm.response.text()).to.include("telefono");
});
Si mandas un body inválido y el servidor responde 500 en vez de 400, encontraste un bug: la API no valida y explota. Repórtalo siempre, aunque "por la UI no se pueda" mandar eso.
Comprueba lo aprendido en el quiz y escribe tus 4 aserciones en el reto.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Qué hace pm.test('...', () => { ... }) en la pestaña Tests?
2. Verificar solo que el status es 200, ¿es suficiente?
3. ¿Cuál es un buen caso negativo para probar en una API?
Reto: 4 aserciones que valen
Toma un GET de tu colección y agrégale en la pestaña Tests: (1) status 200, (2) el tiempo es menor a 800 ms, (3) la respuesta es un objeto con el campo 'id', (4) el 'id' es un número.
Luego haz un request inválido y verifica que responde 400 (o 404), no 500.