¿Qué es API testing?

¿Qué es API testing?

API testing es la práctica de validar una interfaz HTTP, REST, GraphQL o gRPC directamente contra su especificación: forma del contrato, status codes, payloads de respuesta, autenticación, autorización, manejo de errores, rate limits y rendimiento bajo carga. Los tests se saltan la UI por completo y ejercitan el endpoint como lo haría otro servicio.

Como la API suele ser el punto de integración entre servicios (y la superficie contra la que construye un SDK público), los API tests cazan rupturas que los UI tests pierden: drift de esquema, cambios silenciosos retrocompatibilidad-rompedores, flows de auth rotos y violaciones de contrato que no fallan hasta que un consumer downstream parsea la respuesta.

API testing vs UI testing

Ambos validan el sistema; viven en capas distintas.

• UI testing conduce un browser por un flow (login, búsqueda, checkout) y afirma sobre elementos visibles. Lento (segundos por aserción), flaky (red, timing de animación, quirks headless), caro de mantener.
• API testing envía peticiones HTTP directas y afirma sobre status, headers, body. Rápido (decenas de milisegundos por aserción), determinístico (sin superficie de renderizado), barato de mantener. Cubre contrato + preocupaciones de integración a las que la UI no llega.

El reparto pragmático: 80% de cobertura de tests en la capa API, 20% en la capa UI para los pocos flows que los usuarios realmente ven end-to-end. Invertir esa ratio es la causa más común de pipelines CI lentos y flaky.

Qué cubren los API tests

• Validación de contrato. El esquema de respuesta coincide con la spec OpenAPI / GraphQL / protobuf. Tipos de campo, campos requeridos, valores enum. Cazar rupturas en el momento del envío.
• Status codes. 2xx en éxito, 4xx correcto en input malo (400 vs 401 vs 403 vs 404 vs 422), 5xx solo aparece en errores reales de servidor.
• Autenticación y autorización. Peticiones no autenticadas devuelven 401. Peticiones autenticadas del tenant incorrecto devuelven 403. Tokens expiran como se anuncia.
• Edge cases. Arrays vacíos, campos null, strings de max-length, JSON malformado, headers requeridos faltantes, payloads sobredimensionados.
• Idempotencia. Peticiones POST / PUT con una idempotency key aplicada dos veces producen un único side effect.
• Rate limits y cuotas. 429 devuelto en el umbral documentado con Retry-After correcto.
• Rendimiento. p95 latency bajo SLO a carga esperada. Ver load testing para cómo medir.

Cuándo ejecutar API tests

1. En cada PR. Parte de la regression suite. Checks funcionales y de contrato corren en segundos.
2. Smoke post-deploy. Un puñado de checks de endpoint crítico tras cada deploy para confirmar que la API en vivo responde correctamente. Ver smoke testing.
3. Regresión de rendimiento. Ejecuta un load test contra la API al peak esperado antes de cada release. Afirma que p95 + error rate no regresionaron.
4. Sizing de capacidad pre-launch. Ejecuta capacity testing y spike testing contra la API para conocer el techo antes de que llegue el tráfico.

Herramientas clave de API testing

• Postman / Insomnia. Constructores interactivos de peticiones con soporte de collection-runner. Buenos para exploración; las colecciones pueden correr en CI.
• REST-assured (Java), supertest (Node), pytest+requests (Python). API tests code-first viviendo junto al código de aplicación. El default para regression suites.
• Schemathesis, Dredd. Generan casos de test automáticamente desde una spec OpenAPI / GraphQL. Cazan drift de esquema para el que no escribiste tests.
• JMeter y k6. API testing del lado rendimiento. Ambos soportan HTTP, aserciones JSON / XML, headers custom, flows de auth. k6 tiene GraphQL first-class via JS; JMeter maneja SOAP, JDBC, MQTT para APIs no-REST.

Cómo ejecutar tests de rendimiento de API

Un API test funcional confirma que el endpoint devuelve la forma correcta a baja carga. Un test de rendimiento de API confirma que sigue haciéndolo a carga de producción. Ambos importan; el segundo caza el leak que tira la API en día de launch.

En k6, define tu endpoint flow en JavaScript, añade aserciones check() en cada respuesta y configura un escenario ramping-vus al peak esperado. En JMeter, usa un HTTP Request sampler con JSON Path / Response Assertions y un Thread Group dimensionado a la concurrencia esperada.

Ejecuta desde LoadFocus para tráfico desde múltiples regiones cloud golpeando la API simultáneamente. Los consumers reales de API son geo-distribuidos; los load tests single-origin pierden el comportamiento DNS, gateway regional y edge cache que producción golpea.

Si prefieres no escribir los scripts tú mismo, LoadFocus ofrece load testing services donde los ingenieros diseñan escenarios API desde tu spec OpenAPI, los ejecutan a escala y entregan un análisis con desgloses de latencia-por-endpoint y error-rate-por-endpoint.