Cómo analizar un request y response para decidir qué validar

Cuando recibís una respuesta de una API, lo primero que sentís es la tentación de validar todo. El status code, cada campo del body, los headers, el tiempo de respuesta. Y después pasan dos cosas: el test se vuelve frágil porque cualquier cambio menor lo rompe, o te quedás validando cosas que en realidad no le importan a nadie.

El arte está en saber qué vale la pena validar y por qué. Y para eso, antes de escribir una sola línea de código de test, tenés que leer el request y el response con criterio.

Empezá por el request

Antes de mirar el response, fijate bien en el request. El request te dice qué se está pidiendo y con qué intención. Eso determina qué tiene sentido esperar del otro lado.

Preguntate: ¿qué está haciendo este endpoint? ¿Está trayendo datos, creando un recurso, modificando algo, eliminando? El verbo HTTP ya te da una pista enorme.

• Un GET trae información. El foco de validación está en que los datos sean correctos y completos.

• Un POST crea algo. Lo importante es que el recurso se creó bien y que el response refleje eso.

• Un PUT o PATCH modifica. Hay que validar que los cambios se aplicaron y que no rompió lo que no tenía que cambiar.

• Un DELETE elimina. Lo relevante es el status code y confirmar que el recurso ya no existe.

Fijate también en el body del request. Si mandás un payload con 10 campos, preguntate cuáles de esos campos deberían aparecer reflejados en el response. No todos tienen que estarlo, pero algunos sí. Eso ya te da una lista de candidatos a validar.

Leé el response en capas

El response tiene varias capas de información y cada una te dice algo distinto.

El status code

Es lo primero que chequeás, y tiene que matchear con la semántica de la operación.

POST /api/usuarios → 201 Created ✓
GET /api/usuarios/99 → 404 Not Found ✓
GET /api/usuarios/99 → 200 con body vacío ✗

Ese tercer caso pasa más seguido de lo que querés. Un 200 con body vacío cuando debería ser un 404 es un bug disfrazado de éxito, y si solo validás que "devuelve 200", te lo perdés.

Los rangos más frecuentes que vas a ver:

• 2xx → éxito (200 OK, 201 Created, 204 No Content)

• 4xx → error del cliente (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity)

• 5xx → error del servidor (500 Internal Server Error, 503 Service Unavailable)

Validar el status code exacto importa. No es lo mismo que el endpoint devuelva 200 a que devuelva 201. Uno dice "funcionó", el otro dice "se creó un recurso nuevo".

Los headers

No siempre los miramos, pero a veces son críticos. El header Content-Type te dice en qué formato está el body. Si esperás JSON y el servidor te manda text/html, algo explotó en el servidor.

Content-Type: application/json; charset=utf-8 ✓
Content-Type: text/html; charset=utf-8 ✗ (probablemente una página de error)

Otros headers que pueden importar según el contexto: Authorization, X-RateLimit-Remaining, Location (en respuestas 201, te dice dónde quedó el recurso creado), y cualquier header custom que el equipo haya definido.

El body

Acá está la mayor parte de la información, y también donde más fácil es sobrevalidar.

Supongamos este response:

{
  "id": 1042,
  "nombre": "Lucía Fernández",
  "email": "luciaf@empresa.com",
  "rol": "tester",
  "creado_en": "2025-11-14T09:22:00Z",
  "activo": true,
  "preferencias": {
    "idioma": "es",
    "notificaciones": true
  }
}

Antes de validar todo, preguntate: ¿qué necesita ser verdad para que esta operación se considere exitosa?

Si era un POST para crear un usuario, lo importante es:

• Que el id exista (se generó un identificador único).

• Que el email sea el que mandaste en el request.

• Que el activo sea true por defecto.

¿Tiene sentido validar preferencias.idioma? Depende. Si ese valor lo definiste en el request, sí. Si es un default del sistema y no tiene impacto en el negocio que estás probando, probablemente no.

El criterio para decidir

Usá estas preguntas como filtro:

¿Este campo tiene impacto en el negocio o en el comportamiento del sistema? Si el id está mal, probablemente nada funcione después. Si el idioma en preferencias es incorrecto, el usuario ve la UI en inglés en vez de español. Uno es crítico, el otro es importante pero menor.

¿Este valor lo controlás desde el test? Si mandaste el email en el request, validar que ese mismo email esté en el response es sensato. Si el valor lo genera el servidor (timestamps, IDs autoincrement), lo que tiene sentido validar es que el campo exista y tenga el formato correcto, no el valor exacto.

¿Qué pasa si este campo cambia sin avisar? Si validás el valor exacto de un timestamp generado por el servidor, tu test va a fallar en cada ejecución. Mejor validar que el campo sea una fecha válida con el formato esperado.

¿Tiene que ver con el happy path o con un escenario de error? En los errores, el body suele tener un mensaje descriptivo. Ahí sí tiene sentido validar el mensaje o el código de error devuelto, porque es parte del contrato de la API.

Un ejemplo completo

Imaginemos que estás testeando el login de una aplicación.

Request:

POST /api/auth/login
Content-Type: application/json

{
  "email": "tester@freerangetesters.com",
  "password": "Password123"
}

Response exitoso:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expira_en": 3600,
  "usuario": {
    "id": 42,
    "email": "tester@freerangetesters.com",
    "nombre": "Tester Pro"
  }
}

¿Qué validás?

• Status code: 200 OK ✓

• Que token exista y no esté vacío ✓

• Que expira_en sea un número mayor a 0 ✓

• Que usuario.email sea el mismo que mandaste en el request ✓

• El valor exacto del token? No. Cambia en cada login.

• El valor exacto de id? Depende. Si conocés el usuario de antemano, sí. Si no, que sea un número es suficiente.

Response con credenciales inválidas:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "error": "Credenciales inválidas",
  "codigo": "AUTH_001"
}

¿Qué validás acá?

• Status code: 401 ✓

• Que codigo sea "AUTH_001" ✓ (es el contrato definido con el equipo)

• El texto exacto del mensaje de error? Con cuidado, porque los mensajes suelen cambiar. Mejor validar que el campo exista o que contenga ciertas palabras clave.

Cómo aplicarlo en herramientas concretas

Todo esto se vuelve mucho más concreto cuando empezás a trabajar con herramientas reales.

En Postman, podés escribir estas validaciones directamente en la pestaña "Tests" de cada request usando JavaScript. Lo bueno de Postman es que podés explorar la API de forma interactiva primero, analizar el response visualmente, y después escribir las aserciones que tiene sentido. Si querés aprender a hacer esto bien, en freerangetesters.com tenemos el curso de Postman, donde cubrimos desde cómo explorar una API hasta cómo construir colecciones de tests reutilizables con aserciones bien pensadas.

En Rest Assured con Java, el enfoque es diferente: las validaciones las escribís en código directamente, con una sintaxis que describe muy bien la estructura del response. Tenemos también ese curso en freerangetesters.com, donde arrancamos desde cero y llegamos a cubrir escenarios de autenticación, validación de schemas JSON y estructuras de response más complejas.

En ambos casos, la lógica para decidir qué validar es exactamente la misma que describí arriba. La herramienta cambia, el criterio no.

Para profundizar

• Testing REST APIs with Rest Assured – Baeldung — Buena referencia técnica para quienes quieren profundizar en validaciones con Rest Assured.

• Postman Test Scripts documentation — La documentación oficial de Postman para escribir tests, con ejemplos concretos de cómo validar respuestas.

• HTTP Status Codes – MDN — Para tener siempre a mano qué significa cada código y cuándo esperarlo.

• JSON Schema Validation — Si querés validar la estructura completa de un response sin chequear campo por campo.

Para reflexionar

¿Cuántas veces en tu trabajo actual estás validando valores que el servidor genera automáticamente (como IDs o timestamps) en lugar de validar que el campo existe y tiene el formato correcto? ¿Qué impacto tiene eso en la estabilidad de tus tests?

Si tuvieras que elegir las tres validaciones más importantes para el endpoint más crítico de tu aplicación, ¿cuáles serían y por qué?