Rest Assured y Gherkin: ¿Realmente necesario o solo complejidad extra?

Cuando hablamos de automatización de pruebas para APIs en Java, Rest Assured es una de las herramientas más populares. Es sencilla, poderosa y permite escribir pruebas de manera fluida en código. Es sin dudas mi segundo lugar después de Playwright para lidiar con APIs. Sin embargo, algunos equipos deciden agregar Cucumber y escribir los tests en formato Gherkin, lo que plantea la pregunta: ¿es realmente una mejora o solo una capa extra de complejidad?

¿Cómo se usa Gherkin con Rest Assured?

Para los que no estén familiarizados, Cucumber permite escribir pruebas en lenguaje natural usando la sintaxis Gherkin. La idea es que los escenarios sean legibles por cualquier persona del equipo, incluyendo los no técnicos. Esto lo vemos en profundidad en el curso de Selenium con Cucumber para UI/E2E Testing. Un ejemplo de test de API usando Gherkin podría ser:

Feature: Obtener información de un usuario

  Scenario: Consultar un usuario existente
    Given el usuario con ID 1 existe
    When se consulta la API con ese ID
    Then la respuesta debe ser 200 OK
    And el nombre del usuario debe ser "John Doe"

A diferencia del uso tradicional de Gherkin en pruebas de UI, donde los pasos suelen representar interacciones con la interfaz gráfica, en pruebas de API con Rest Assured, los steps en Gherkin terminan describiendo llamadas HTTP y validaciones de respuesta. Esto lleva a una implementación en Java que encapsula estas acciones en métodos dentro de los step definitions:

@Given("el usuario con ID {int} existe")
public void elUsuarioExiste(int id) {
    // Verificar que el usuario exista en la base de datos (mock o real)
}

@When("se consulta la API con ese ID")
public void consultarUsuario() {
    response = given()
        .when()
        .get("https://api.ejemplo.com/users/1")
        .then()
        .extract()
        .response();
}

@Then("la respuesta debe ser 200 OK")
public void verificarCodigoRespuesta() {
    response.then().statusCode(200);
}

@Then("el nombre del usuario debe ser \"(.*)\"")
public void verificarNombreUsuario(String nombreEsperado) {
    response.then().body("name", equalTo(nombreEsperado));
}

El problema con este enfoque es que Rest Assured ya tiene una forma de escribir pruebas en un estilo fluido que se asemeja bastante al lenguaje natural, eliminando la necesidad de una capa intermedia como Gherkin. ¿Ves ese "when" o "then" adentro del otro "when" o "then"? Eso ya me empieza a dar la pauta de que es al divino botón. Veamos por qué sumar Cucumber a Rest Assured puede ser una mala idea.

¿Por qué creo que sumar Cucumber a Rest Assured es innecesario?

Si bien Cucumber puede ser muy útil para pruebas funcionales o de aceptación en UI, en el contexto de pruebas de APIs con Rest Assured, su valor agregado es muy discutible. En mi experiencia, agregar Cucumber a pruebas de API introduce más problemas de los que resuelve. Algunas razones son:

1. El lenguaje natural no aporta claridad

• La sintaxis de Gherkin busca hacer los tests comprensibles para personas no técnicas, pero en pruebas de API, la mayoría de los involucrados ya son técnicos (QA, developers, DevOps).

• Leer un test en código Rest Assured es tan claro como leerlo en Gherkin, sin la sobrecarga de los step definitions.

2. Mayor esfuerzo en mantenimiento

• Cada cambio en la API requiere actualizar los steps en Java y los escenarios en Gherkin.

• Si una API cambia de estructura o comportamiento, modificar solo código Rest Assured es más rápido que modificar Gherkin + Step Definitions.

3. Menor flexibilidad

• Al escribir pruebas en Java con Rest Assured, tienes total control sobre cómo manejar respuestas, parsear datos y hacer validaciones avanzadas.

• Con Cucumber, las pruebas terminan más acopladas a estructuras fijas, limitando su flexibilidad.

4. No es necesario para la reutilización de código

• Uno de los argumentos para usar Gherkin es la reutilización de steps, pero en Rest Assured esto se logra fácilmente con métodos reutilizables o librerías internas.

Un ejemplo de código sin Cucumber que hace lo mismo que el ejemplo anterior, pero sin la capa de complejidad extra:

@Test
public void testConsultarUsuario() {
    given()
    .when()
        .get("https://api.ejemplo.com/users/1")
    .then()
        .statusCode(200)
        .body("name", equalTo("John Doe"));
}

La prueba es clara, directa y no necesita steps adicionales.

Conclusión

Si bien Cucumber es una gran herramienta en pruebas de UI o aceptación, su uso con Rest Assured en pruebas de API es, en mi opinión, innecesario. No aporta mejoras en legibilidad ni reutilización y, en cambio, introduce una capa extra de complejidad y mantenimiento. Para la mayoría de los proyectos, escribir las pruebas directamente en Rest Assured es la opción más eficiente y sostenible.

Si quieres aprender más sobre cómo automatizar pruebas de APIs con Rest Assured , te recomiendo revisar el curso de API Automation con Rest Assured acá en la web.

¿Qué opinas? ¿Usaste Gherkin con Rest Assured en tus proyectos? ¿Te pareció útil o creés que agrega complejidad innecesaria? ¡Dejamelo en los comentarios!