Postman sin assertions es solo un cliente HTTP bonito
11 validaciones con pm.test: status codes, cookies de autenticación, estructura JSON y TotalCount. De "No tests found" a un flujo que realmente testea.
Post
En el post anterior resolví el problema del CSRF dinámico. Las 3 requests corrían con 200. El flujo era estable.
Pero había un problema que se veía claro en el Collection Runner:
"No tests found".
En las 3 requests. Las 3.
Eso significa que Postman ejecutaba las requests, recibía respuestas, y no validaba nada. Los 200 verdes eran solo status codes del servidor. No había ninguna verificación de que la response tuviera la estructura esperada, las cookies correctas, o los datos que debería tener.
Sin assertions, Postman es un cliente HTTP con buena interfaz. No es una herramienta de testing.
Este post cambia eso.
Qué es pm.test
pm.test es la función de Postman para escribir assertions. Va en la pestaña Scripts → Post-response de cada request.
La sintaxis es esta:
pm.test("Nombre del test", function () {
pm.expect(algo).to.equal(otraCosa);
});
Cada pm.test aparece como una línea en el Collection Runner: verde si pasa, roja si falla. Es lo que convierte a Postman en una herramienta de testing real.
GET - Login Page: 3 assertions
Esta request carga la página de login. En los posts anteriores de DevTools ya sabía qué esperar: status 200, HTML, y una cookie CSRF-TOKEN.
Las assertions:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response is HTML", function () {
pm.response.to.have.header("Content-Type");
pm.expect(pm.response.headers.get("Content-Type")).to.include("text/html");
});
pm.test("CSRF-TOKEN cookie exists", function () {
const csrfCookie = pm.cookies.get("CSRF-TOKEN");
pm.expect(csrfCookie).to.not.be.undefined;
});
Por qué estas 3:
La primera es obvia: si el status no es 200, algo se rompió antes de empezar.
La segunda verifica que la response sea HTML. Si algún día el endpoint cambia y devuelve JSON o un redirect, este test lo detecta.
La tercera es la más importante de esta request: verificar que la cookie CSRF-TOKEN exista. Sin ella, el POST de login que viene después va a fallar. Esto conecta directamente con el problema del CSRF dinámico que resolví en el post anterior.
POST - Login: 3 assertions
Esta request envía las credenciales al backend. Lo que espero: status 200, cookie de autenticación presente, y CSRF-TOKEN todavía disponible.
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("AspNetAuth cookie exists after login", function () {
const authCookie = pm.cookies.get(".AspNetAuth");
pm.expect(authCookie).to.not.be.undefined;
});
pm.test("CSRF-TOKEN cookie still present", function () {
const csrfCookie = pm.cookies.get("CSRF-TOKEN");
pm.expect(csrfCookie).to.not.be.undefined;
});
El error con el nombre de la cookie
Acá tuve un problema. El primer intento del test de autenticación falló:
FAIL AspNetAuth cookie exists after login | AssertionError: expected undefined not to be undefined
El test buscaba la cookie como "AspNetAuth" (sin punto). Pero en la cookie jar de Postman el nombre real era .AspNetAuth (con punto al inicio).
La diferencia es un punto. Un carácter. Y eso hace que el test pase o falle.
Es el tipo de detalle que en DevTools podés pasar por alto porque ves el nombre en una tabla y lo leés como "AspNetAuth". Pero cuando lo buscás programáticamente, el nombre tiene que ser exacto.
La corrección:
// Antes (falla):
const authCookie = pm.cookies.get("AspNetAuth");
// Después (funciona):
const authCookie = pm.cookies.get(".AspNetAuth");
Después de corregir: las 3 assertions de Login pasaron.
POST - Customer List: 5 assertions
Esta es la request más importante del flujo. Trae los datos reales de la grilla de clientes. Y es donde las assertions se ponen más interesantes.
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response is JSON", function () {
pm.response.to.have.header("Content-Type");
pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});
pm.test("Response has Entities array", function () {
const jsonData = pm.response.json();
pm.expect(jsonData).to.have.property("Entities");
pm.expect(jsonData.Entities).to.be.an("array");
});
pm.test("TotalCount is 91", function () {
const jsonData = pm.response.json();
pm.expect(jsonData.TotalCount).to.eql(91);
});
pm.test("Each entity has CustomerID and CompanyName", function () {
const jsonData = pm.response.json();
jsonData.Entities.forEach(function (entity) {
pm.expect(entity).to.have.property("CustomerID");
pm.expect(entity).to.have.property("CompanyName");
});
});
Por qué estas 5:
Las dos primeras (status y content-type) son el piso mínimo.
La tercera verifica que la response tenga la estructura esperada: un campo Entities que sea un array. Si algún día el backend cambia la estructura de la response, este test lo detecta.
La cuarta valida TotalCount: 91. Esto lo sabía desde el análisis en DevTools: la grilla tiene 91 clientes. Si ese número cambia, algo pasó con los datos.
La quinta recorre cada entidad del array y verifica que tenga CustomerID y CompanyName. Son los campos mínimos que la grilla necesita para funcionar. Si alguna entidad viene sin CustomerID, hay un problema en el backend.
Este último test es el más potente de todos porque no valida un solo dato: valida la estructura de los 91 registros de una sola vez.
Resultado: de 0 a 11
| Request | Tests | Qué valida |
|---|---|---|
| GET - Login Page | 3 | Status, HTML, cookie CSRF |
| POST - Login | 3 | Status, cookie auth, cookie CSRF |
| POST - Customer List | 5 | Status, JSON, Entities, TotalCount, campos obligatorios |
| Total | 11 |
Antes: "No tests found" en las 3 requests. Ahora: 11 assertions que verifican el flujo completo.
Qué cambió
Este paso parece chico pero cambia la naturaleza de la colección.
Antes, las requests solo confirmaban que el servidor respondía. Ahora verifican que responda correctamente: con las cookies esperadas, con la estructura de datos correcta, con la cantidad de registros esperada, y con los campos obligatorios presentes en cada entidad.
Eso es la diferencia entre "usar Postman" y "hacer API testing con Postman".
Próximo paso
Las 11 assertions validan el flujo exitoso. Pero un flujo real también necesita validar qué pasa cuando las cosas salen mal: credenciales incorrectas, campos vacíos, CSRF roto a propósito.
Eso es testing negativo. Y es el siguiente post.