¿Qué es el API testing?

¿Qué es el API testing?

El API testing consiste en enviar peticiones directamente a una API y comparar la respuesta con lo que promete la especificación: código de estado, cabeceras, forma del payload, autenticación, gestión de errores y tiempo de respuesta. No interviene ningún navegador ni interfaz. La prueba llama al endpoint como lo haría otro servicio o un SDK, así que detecta roturas del contrato antes de que las note un consumidor.

Cómo funciona el API testing

Una prueba es una petición más aserciones. Eliges un endpoint, defines método, cabeceras, auth y cuerpo, lo envías y compruebas lo que vuelve. Encadena peticiones cuando una llamada depende de otra (crear un pedido y luego consultarlo con el id devuelto).

POST /orders
Authorization: Bearer <token>
{"sku": "A-100", "qty": 2}

assert status == 201
assert body.id es un string
assert body.qty == 2
assert tiempo de respuesta < 300 ms

Ejecuta las mismas comprobaciones en un runner de tests en cada pull request, y un conjunto reducido contra la API en producción de forma programada.

Qué cubren las pruebas de API

• Contrato. Nombres de campo, tipos y campos obligatorios coinciden con el esquema OpenAPI o GraphQL.
• Códigos de estado. 2xx si todo va bien, el 4xx correcto ante entradas inválidas (400, 401, 403, 404, 422), 5xx solo en fallos reales del servidor.
• Autenticación y autorización. Sin token, 401; con el token de otro tenant, 403; los tokens caducados se rechazan.
• Casos límite. Arrays vacíos, campos nulos, longitudes máximas, JSON malformado, cabeceras ausentes, cuerpos enormes.
• Límites de uso. Un 429 en el umbral documentado, con un Retry-After razonable.
• Rendimiento. Latencia y tasa de errores con la carga esperada. Mira las métricas de rendimiento de API.

API testing frente a pruebas de UI

Las pruebas de UI conducen un navegador por un flujo y comprueban lo visible. Son lentas y se rompen cuando cambia el diseño. Las pruebas de API comprueban las respuestas directamente, se ejecutan en milisegundos y fallan por un único motivo. La mayoría de equipos pone el grueso de las comprobaciones en la capa de API y deja pocas pruebas de UI para los recorridos que los usuarios realmente hacen. Ambas encajan en las pruebas de regresión.

Tipos de pruebas de API

• Pruebas funcionales y de contrato verifican la corrección frente a la especificación.
• Pruebas de integración verifican que los servicios funcionan juntos, a menudo contra un stub de API mocking cuando falta una dependencia.
• Pruebas de seguridad examinan auth, inyección y exposición excesiva de datos.
• Smoke tests llaman a unos pocos endpoints críticos tras un despliegue. Consulta la guía de smoke testing (en inglés).
• Pruebas de carga miden velocidad y errores con tráfico concurrente. Mira load testing.
• Monitorización repite las comprobaciones de forma programada en producción. Mira la monitorización de API.

Errores habituales

• Comprobar solo el código de estado. Un 200 con el cuerpo equivocado sigue siendo un fallo.
• Probar solo el camino feliz y olvidar los fallos de auth y las entradas inválidas.
• Compartir datos de prueba mutables entre tests, de modo que el orden cambia el resultado.
• Fijar tokens y URLs en el código en vez de usar variables por entorno.
• Lanzar las pruebas de rendimiento desde una sola máquina junto al servidor, lo que oculta efectos de red y de región.
• No probar nunca contra producción, de modo que un despliegue que funciona en staging falla sin que nadie lo vea.

Herramientas y dónde encaja LoadFocus

Los runners en código (pytest con requests, supertest, REST-assured) sirven para suites de regresión. Postman y clientes similares sirven para explorar. Las herramientas guiadas por especificación, como Schemathesis, generan casos a partir de un archivo OpenAPI.

• curl online envía una petición desde servidores de LoadFocus y muestra estado, cabeceras, cuerpo y un desglose de tiempos. Es una comprobación puntual, y las redirecciones se informan en lugar de seguirse.
• El API status checker comprueba una URL pública desde 6 regiones de AWS a la vez. Es una instantánea, sin programación, historial ni alertas.
• La monitorización de API ejecuta comprobaciones programadas sobre códigos de estado, cuerpos de respuesta, cabeceras y tiempo de respuesta, con alertas por email, Slack, Microsoft Teams y otros canales. El plan gratuito comprueba cada 5 minutos; los planes de pago, con más frecuencia.
• OpenAPI a k6 convierte una especificación OpenAPI o Swagger en un script de k6 en tu navegador. Puedes ejecutarlo en la plataforma de load testing, que lanza JMeter y k6 desde 25 regiones cloud.

Qué pueden y qué no pueden hacer los probadores en el navegador se explica en la guía del probador de API online (en inglés).

Preguntas frecuentes: API testing

¿El API testing es lo mismo que el testing unitario?

No. Una prueba unitaria comprueba una función aislada. Una prueba de API llama al servicio en ejecución por HTTP y comprueba el contrato que expone, así que también ejercita el enrutado, la auth, la serialización y a menudo la base de datos.

¿Necesito saber programar para probar APIs?

Para empezar, no. Un cliente como curl o un constructor de peticiones basta para enviar peticiones y leer respuestas. Al automatizar en CI aparece el código o un archivo de configuración.

¿Cada cuánto deben ejecutarse las pruebas de API?

Las funcionales y de contrato en cada pull request, unas pocas críticas tras cada despliegue y un subconjunto programado en producción para enterarte de las caídas antes que tus usuarios.

¿Qué diferencia hay entre API testing y monitorización de API?

El testing se ejecuta antes del lanzamiento para encontrar defectos. La monitorización repite comprobaciones contra la API en producción y te avisa cuando algo falla o se ralentiza.