Testeás APIs hace un tiempo. Sabés mandar un GET, un POST, validar que el status code sea 200. Y sin embargo, los bugs igual se escapan. ¿Por qué?

Porque hay errores que se cometen tan seguido que ya parecen parte del proceso. En este post te cuento tres errores que veo una y otra vez al testear APIs, tanto en testers que están arrancando como en equipos con años de experiencia.

Error 1: Verificar solo el status code

Este es el más común y el más peligroso. El test pasa, el status code es 200, y todo el mundo festeja. Pero nadie miró el body de la respuesta.

Esto es lo que suele pasar:

Response response = given()
    .get("/api/usuarios/123");

assertEquals(200, response.getStatusCode()); // ✅ pasa

¿Y el body? ¿Y los campos? ¿Y si la API devolvió un 200 con un body vacío? ¿O con datos de otro usuario? ¿O con un error envuelto en un 200 porque alguien tomó malas decisiones de diseño?

Un 200 no significa que la API funcionó. Significa que el servidor te respondió sin explotar. Es muy distinto.

Te cuento algo...estas últimas semanas estuve entrevistando gente para puestos de Senior Test Engineer en BackEnd. En la entrevista técnica les mostraba código, avisando que había cosas mal a propósito, malas prácticas y todo tipo de aberraciones. Casi nadie veía que solo validábamos status code. Increíble pero cierto...

Lo que deberías estar haciendo:

Response response = given()
    .get("/api/usuarios/123");

assertEquals(200, response.getStatusCode());
assertEquals("Juan Pérez", response.jsonPath().getString("nombre"));
assertEquals("juan@email.com", response.jsonPath().getString("email"));
assertNotNull(response.jsonPath().getString("id"));

Y si usás Rest Assured con todas las chuchadas que trae, podés validar el schema completo de la respuesta. Pero eso lo dejamos para el error 3.

Error 2: Ignorar los casos negativos

La mayoría de los tests de API se escriben pensando en el happy path. El usuario existe, el token es válido, los datos están bien formateados. Todo perfecto.

Pero las APIs viven en producción, donde la gente manda requests con IDs que no existen, tokens vencidos, campos vacíos y combinaciones que ningún developer imaginó.

Algunos escenarios que casi nunca se testean:

• ¿Qué pasa si mandás un ID que no existe? ¿Da 404 con un mensaje claro o explota con un 500?

• ¿Qué pasa si el token está vencido? ¿Da 401 o igual deja pasar?

• ¿Qué pasa si mandás un body malformado? ¿Da 400 con detalle del error o da 500?

• ¿Qué pasa si mandás un campo requerido vacío?

Ejemplo de cómo testear el caso negativo en Rest Assured:

@Test
public void usuarioInexistenteDeberiaDar404() {
    given()
        .pathParam("id", 99999)
    .when()
        .get("/api/usuarios/{id}")
    .then()
        .statusCode(404)
        .body("mensaje", equalTo("Usuario no encontrado"));
}

Si tu suite de tests no tiene tests negativos, no estás testeando la API. Estás documentando el happy path y no preparándote para no tan happy clientes.

Error 3: No validar el schema de la respuesta

Este es el más sofisticado de los tres y el que más bugs deja pasar sin que nadie se dé cuenta.

Un schema validation no verifica si el campo nombre tiene el valor "Juan". Verifica que el campo nombre exista, que sea un String, y que la estructura completa de la respuesta sea la que el contrato de la API dice que tiene que ser.

¿Por qué importa? Porque los developers a veces cambian la API sin avisar. Renombran un campo. Cambian un tipo de dato. Agregan un nivel de anidamiento. Y si tu test solo chequeaba el status code, ese cambio pasa invisible hasta que el frontend explota en producción.

Con Rest Assured podés validar schemas JSON de manera muy limpia:

@Test
public void responseDebeMatchearElSchema() {
    given()
        .get("/api/usuarios/123")
    .then()
        .statusCode(200)
        .body(matchesJsonSchemaInClasspath("schemas/usuario-schema.json"));
}

Y el schema en usuario-schema.json:

{
  "$schema": "<http://json-schema.org/draft-07/schema#>",
  "type": "object",
  "required": ["id", "nombre", "email"],
  "properties": {
    "id": { "type": "integer" },
    "nombre": { "type": "string" },
    "email": { "type": "string", "format": "email" }
  }
}

Si mañana el developer cambia nombre por fullName, tu test falla automáticamente. Sin que tengas que saber que el cambio ocurrió.

El resumen que necesitás

Estos tres errores tienen algo en común: todos se cometen por testear lo mínimo indispensable y dar por sentado que si el status code está bien, todo está bien.

Testar solo el status code es como revisar que el auto arrancó sin mirar si tiene frenos.

Los tests de API de calidad verifican la respuesta completa, cubren los casos negativos, y validan que el contrato entre cliente y servidor se respete con el tiempo.

Si querés aprender a construir suites de API testing completas con Java y Rest Assured, cubriendo todo esto y mucho más, te recomiendo nuestro curso API Automation con Java y Rest Assured, donde arrancamos desde cero y llegamos a frameworks de automatización reales y mantenibles.

¿Cuál de estos tres errores estabas cometiendo? Te leo en los comentarios.