Applying API testing frameworks: real-world code examples

Applying API testing frameworks: real-world code examples
Modern applications dependen de APIs para conectar frontends, servicios internos y terceros. Validar estas APIs de forma automática es clave para evitar regresiones y detectar errores antes de llegar a producción. En este artículo verás cómo aplicar marcos de prueba de API con ejemplos reales usando Postman (JavaScript) y Rest Assured (Java), y cómo integrarlos en un flujo de CI/CD.​

Why API testing matters
API testing permite validar lógica de negocio, contratos y reglas de seguridad sin necesidad de una interfaz gráfica. Cuando se integra en pipelines de CI/CD, ayuda a detectar fallos de manera temprana y a mantener lanzamientos frecuentes pero estables. Además, automatizar estas pruebas reduce el trabajo manual del QA y mejora la confianza en cada despliegue.​

Choosing an API testing framework
Existen múltiples herramientas para probar APIs: Postman, Rest Assured, Karate, JMeter, SoapUI, entre otras. Cada una ofrece ventajas según el lenguaje, el tipo de proyecto y el nivel de experiencia del equipo. En este artículo nos centraremos en dos opciones muy usadas en la industria: Postman para flujos rápidos y colaborativos, y Rest Assured para pruebas integradas en suites Java.​

Postman: testing with JavaScript
Postman es una herramienta muy popular para diseñar, documentar y probar APIs, tanto de forma manual como automatizada. Permite agrupar peticiones en Collections, usar entornos con variables, y añadir scripts en JavaScript para ejecutar aserciones sobre las respuestas.​

Un flujo típico de prueba funcional en Postman incluye:

Definir la petición (método, URL, headers, body).

Añadir scripts en la pestaña “Tests” para validar el resultado.

Ejecutar la Collection de manera local o en un pipeline CI/CD.

Real-world example: validating a GET endpoint in Postman
Supongamos una API de librería con el endpoint GET /books/{id} que devuelve los detalles de un libro. El objetivo de la prueba es validar que el servicio responde con código 200 y que el cuerpo incluye campos como id, title y author con datos válidos.​

En Postman, la prueba podría incluir aserciones como:

js
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

pm.test("Response body has required fields", function () {
const json = pm.response.json();
pm.expect(json).to.have.property("id");
pm.expect(json).to.have.property("title");
pm.expect(json).to.have.property("author");
});

pm.test("Book id matches requested id", function () {
const json = pm.response.json();
const requestedId = pm.request.url.variables.get("id");
pm.expect(json.id.toString()).to.eql(requestedId);
});
Este tipo de script se ejecuta automáticamente después de cada llamada y te permite validar tanto el código de estado como la estructura del JSON.​

Data-driven tests with Postman
En escenarios reales, es habitual probar el mismo endpoint con distintos datos de entrada. Postman soporta pruebas orientadas a datos usando archivos CSV o JSON, donde cada fila representa un conjunto de variables para la ejecución.​

Por ejemplo, un archivo CSV podría contener varios bookId y valores esperados, y la Collection Runner los iterará de manera automática. Esto permite cubrir casos positivos y negativos (IDs válidos, inexistentes o inválidos) sin duplicar manualmente las peticiones.​

Rest Assured: Java-based API testing
Rest Assured es un framework para pruebas de API en Java que simplifica el envío de peticiones HTTP y la validación de respuestas. Se integra bien con TestNG o JUnit, lo que facilita su uso dentro de suites automatizadas y pipelines de CI/CD.​

Su enfoque fluido permite escribir pruebas legibles, y combinarlo con librerías como Hamcrest para aserciones expresivas sobre JSON y XML. Además, soporta múltiples métodos HTTP, autenticación, parámetros, logs y manejo de serialización/deserialización.​

Real-world example: Rest Assured GET test
Tomando el mismo escenario de GET /books/{id}, una prueba en Rest Assured podría validar el status code y campos clave de la respuesta JSON.​

java
import static io.restassured.RestAssured.;
import static org.hamcrest.Matchers.;
import org.testng.annotations.Test;

public class BookApiTest {

@Test
public void getBookById_shouldReturnValidBook() {
    given()
        .baseUri("https://api.example.com")
        .basePath("/books/{id}")
        .pathParam("id", 1)
    .when()
        .get()
    .then()
        .statusCode(200)
        .body("id", equalTo(1))
        .body("title", notNullValue())
        .body("author", notNullValue());
}

}
Este tipo de prueba se puede ejecutar junto con el resto del suite de tests de backend, formando parte del proceso de build.​

Creating reusable components in Rest Assured
En casos reales, resulta útil extraer configuraciones repetidas como baseUri, headers comunes o autenticación a una clase base. De esta forma, las pruebas se enfocan en el comportamiento, no en el detalle de configuración de cada endpoint.​

Por ejemplo, se puede definir una clase BaseApiTest que configure Rest Assured en un método @BeforeClass y luego extenderla desde las clases que representan cada módulo de la API (books, users, orders, etc.).​

Testing authenticated APIs
Muchos servicios exponen endpoints protegidos mediante API keys, tokens Bearer u OAuth2. Tanto Postman como Rest Assured ofrecen soporte para este tipo de autenticación, ya sea configurando headers, usando helpers integrados o generando tokens previos a las pruebas.​

En Rest Assured, por ejemplo, se puede añadir un header de autorización de forma global o en cada prueba:

java
given()
.baseUri("https://api.example.com")
.header("Authorization", "Bearer " + token)
.when()
.get("/books")
.then()
.statusCode(200);
En Postman, puedes almacenar el token en una variable de entorno y referenciarlo en el header Authorization mediante {{token}}.​

Integrating API tests into CI/CD
El verdadero valor de estos marcos se ve cuando se integran en pipelines de CI/CD como GitHub Actions, Jenkins o GitLab CI. La idea es ejecutar suites de pruebas de API en cada push o antes de un despliegue para evitar que cambios en el código rompan contratos existentes.​

Algunos enfoques habituales son:

Ejecutar Collections de Postman mediante Newman en un job del pipeline.

Ejecutar tests de Rest Assured con Maven/Gradle como parte del stage de test.

Publicar reportes (HTML, JUnit) como artefactos del pipeline para su revisión.

Example: running Postman tests in CI
Newman, el CLI de Postman, permite ejecutar collections dentro de un flujo automatizado. Un paso típico en un pipeline podría incluir un comando como:​

bash
newman run LibraryAPI.postman_collection.json \
-e staging.postman_environment.json \
--reporters cli,junit \
--reporter-junit-export newman-report.xml
Ese reporte puede ser consumido por la plataforma de CI/CD para marcar el build como exitoso o fallido según los resultados de las pruebas.​

Example: running Rest Assured in CI
Para proyectos Java, lo más habitual es ejecutar los tests de Rest Assured junto con el resto de pruebas unitarias e integradas. En un pipeline que use Maven, bastaría con un job que ejecute mvn test y recoja los informes generados.​

Combinado con herramientas de reporte como surefire-report o plugins de informes HTML, es posible ver en detalle qué endpoints fallaron, qué payload se envió y cuál fue la respuesta recibida.​

Putting it all together
Aplicar marcos de prueba de API en proyectos reales significa ir más allá de pruebas manuales puntuales y construir suites automatizadas que vivan junto al código. Usando Postman puedes cubrir rápidamente escenarios funcionales y colaborativos, mientras que Rest Assured te permite integrar pruebas de API directamente en tu base de código Java y pipeline de CI/CD.​

Al combinar ambos enfoques, obtienes una cobertura robusta: validaciones funcionales, pruebas con datos, escenarios autenticados y ejecución continua en cada cambio. Esto se traduce en APIs más confiables, menos incidentes en producción y un ciclo de desarrollo más seguro y predecible