API testing de cero a profesional: la guía práctica

El testing de API es el mejor ratio esfuerzo/valor de toda la pirámide: más rápido y estable que e2e, más cercano al negocio que el unit test. Y sigue siendo el gran ausente en la mayoría de los equipos que "prueban por la UI".

Qué validar en cada respuesta (los 5 niveles)

La mayoría se queda en el nivel 1. Los bugs viven del 2 hacia abajo:

1. Status code — 201 al crear, 400 al mandar basura, 401 sin token. El mínimo.
2. Shape del body — ¿están todos los campos del contrato, con el tipo correcto? Un precio: "12000" (string) donde iba número rompe frontends en silencio.
3. Reglas de negocio — ¿el descuento se aplicó? ¿la reserva quedó en el horario pedido? ¿el total suma?
4. Efectos colaterales — el POST creó la reserva… ¿y el GET posterior la devuelve? ¿el contador de cupos bajó?
5. Headers y metadatos — paginación correcta, Content-Type, cache, CORS.

Los casos que nadie prueba (y explotan en producción)

• Autorización cruzada: el usuario A pide GET /bookings/{id-de-B}. ¿403, o le muestra los datos de B? Este bug (IDOR) es de los más comunes y graves del mundo real.
• Payload gigante: un nombre de 10.000 caracteres. ¿400 limpio o 500?
• Doble envío: el mismo POST dos veces (usuario impaciente + red lenta). ¿Idempotencia o duplicado?
• Campos extra: manda {"precio": 1} en un endpoint que no debería aceptar precio del cliente. ¿Lo ignora o lo usa (bug de seguridad)?
• Paginación en los bordes: página 0, página -1, página 99999, limit=0.

De Postman manual a colección automatizada

Postman deja de ser clicks cuando usas tests en las requests:

// Tab "Tests" de la request
pm.test("crea la reserva", () => {
  pm.response.to.have.status(201);
  const body = pm.response.json();
  pm.expect(body.id).to.be.a("number");
  pm.collectionVariables.set("bookingId", body.id); // encadena requests
});

Y la colección completa corre en CI con Newman:

newman run reservas.postman_collection.json -e staging.postman_environment.json

¿Y en código? Las opciones serias

Cuando la colección crece, el código escala mejor que el JSON de Postman:

• Playwright request — si ya tienes Playwright, es gratis: mismo runner, mismos reportes (lo cubrimos en la lección de API testing).
• pytest + requests/httpx — el estándar Python: fixtures para auth, parametrize para las matrices de casos.
• Contratos con schema: valida el shape contra un JSON Schema/OpenAPI en vez de campo por campo — un cambio de contrato rompe el build, no producción.

La estrategia sana

API tests para reglas de negocio y contratos (muchos, rápidos) + e2e de UI para los flujos críticos (pocos) + el smoke de integración real. Probar reglas de negocio por UI es pagar precio de e2e por valor de API test.

---

Para partir desde cero: la lección de pruebas de API del curso gratuito de QA Manual no asume nada y te deja haciendo tu primer CRUD completo en Postman.