Que Es una API?

Una API (Application Programming Interface) es un contrato entre dos sistemas de software. Define como un sistema puede solicitar datos o acciones de otro y en que formato vendra la respuesta. Piensa en ella como un mesero en un restaurante: tu (el cliente) haces un pedido, el mesero (la API) lo lleva a la cocina (el servidor), y te trae tu comida (la respuesta).

En el desarrollo de software moderno, las APIs estan en todas partes. Cuando consultas el clima en tu celular, la app envia un API request a un servicio meteorologico. Cuando inicias sesion con Google en un sitio de terceros, las APIs de OAuth manejan la autenticacion. Cuando tu app bancaria muestra tu saldo, llama a la API del backend del banco.

APIs en la Arquitectura Moderna

La mayoria de las aplicaciones modernas siguen una arquitectura cliente-servidor donde el frontend (aplicacion web o movil) se comunica con el backend a traves de APIs. Esta separacion se ha convertido en el estandar porque permite:

  • Multiples clientes usando el mismo backend (web, iOS, Android, integraciones de socios)
  • Desarrollo independiente donde los equipos de frontend y backend trabajan en paralelo
  • Escalabilidad ya que cada capa puede escalarse independientemente
  • Reutilizacion donde la misma API sirve a diferentes productos y funcionalidades

Una aplicacion tipica de e-commerce puede tener docenas de APIs: una para autenticacion de usuarios, otra para el catalogo de productos, una para el carrito de compras, otra para pagos, y asi sucesivamente.

Por Que Importa el Testing de API

La Perspectiva de la Piramide de Testing

La piramide de testing, introducida por Mike Cohn, sugiere que tu suite de tests deberia tener muchos unit tests en la base, menos tests de integracion/API en el medio, y aun menos tests de UI en la parte superior. Los tests de API ocupan esa capa intermedia crucial porque:

  1. Se ejecutan mas rapido que los tests de UI — sin renderizado de navegador, sin cargas de pagina, sin esperar animaciones
  2. Son mas estables que los tests de UI — sin selectores de elementos inestables ni problemas de timing
  3. Cubren mas logica — una sola API puede servir multiples pantallas de UI
  4. Detectan bugs de integracion — verifican como se comunican los diferentes servicios

Impacto en el Mundo Real

Considera este escenario: tu sitio de e-commerce tiene un flujo de checkout. Un test de UI podria tomar 30-60 segundos para llenar formularios, hacer clics en botones y verificar el resultado. El test de API equivalente — enviando un POST request a /api/orders con el payload del pedido — toma menos de 1 segundo y testea la misma logica de negocio.

En Google (Waze), el testing de API era critico porque la app movil dependia de docenas de servicios backend. Una API rota podia afectar a mas de 150 millones de usuarios. Detectar problemas en la capa de API antes de que lleguen a la UI ahorraba enormes cantidades de tiempo de debugging.

Que Cubre el Testing de API

El testing de API valida varios aspectos del backend:

AspectoQue TesteasEjemplo
FuncionalidadRespuestas correctas para requests validosGET /users/123 retorna el usuario correcto
ValidacionManejo adecuado de input invalidoPOST /users con email faltante retorna 400
Status codesCodigos de estado HTTP apropiadosDELETE /users/123 retorna 204 en caso de exito
Integridad de datosLos datos de respuesta coinciden con la base de datosEl usuario creado aparece en la lista GET /users
PerformanceTiempo de respuesta dentro de los SLAsLa API responde en menos de 200ms
SeguridadAutenticacion y autorizacionUsuarios no autorizados reciben 401/403

Conceptos Fundamentales

Request y Response

Cada interaccion con una API sigue un patron de request-response:

Request consiste en:

  • URL/Endpoint — a donde enviar el request (ej., https://api.example.com/users)
  • Method — que accion tomar (GET, POST, PUT, DELETE)
  • Headers — metadata como tokens de autenticacion, tipo de contenido
  • Body — datos del payload (para requests POST/PUT)

Response consiste en:

  • Status code — indicador numerico de exito o falla (200, 404, 500)
  • Headers — metadata como tipo de contenido, informacion de rate limit
  • Body — los datos reales retornados (generalmente JSON o XML)
Request:
GET /api/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json

Response:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alice Johnson",
  "email": "alice@example.com",
  "role": "admin"
}

Tipos de APIs

Aunque este modulo se enfoca principalmente en REST APIs (el tipo mas comun), debes conocer el panorama:

  • REST — basado en recursos, usa metodos HTTP, respuestas JSON (mas comun)
  • GraphQL — lenguaje de consulta, el cliente especifica exactamente que datos necesita
  • gRPC — alto rendimiento, usa Protocol Buffers, comun en microservicios
  • SOAP — basado en XML, contrato estricto, comun en sistemas enterprise/legacy
  • WebSocket — bidireccional, comunicacion en tiempo real

Cubrimos cada uno de estos en lecciones dedicadas mas adelante en este modulo.

Enfoques del Testing de API

Testing Manual de API

Al comenzar, el testing manual con herramientas como Postman o cURL te da retroalimentacion inmediata y te ayuda a entender como funcionan las APIs. Enviaras requests, inspeccionaras responses y verificaras el comportamiento de forma interactiva. Esto es excelente para:

  • Testing exploratorio de nuevos endpoints
  • Debugging de problemas especificos
  • Aprender como se comporta una API antes de escribir tests automatizados
  • Verificacion rapida durante el desarrollo

Testing Automatizado de API

A medida que tu suite de tests crece, la automatizacion se vuelve esencial. Los tests automatizados de API pueden:

  • Ejecutarse en pipelines de CI/CD en cada cambio de codigo
  • Cubrir cientos de escenarios en segundos
  • Detectar regresiones inmediatamente
  • Servir como documentacion viva del comportamiento esperado

Las herramientas comunes de automatizacion incluyen REST Assured (Java), pytest + requests (Python), Supertest (Node.js), y Postman/Newman para testing basado en colecciones.

Contract Testing

El contract testing verifica que una API cumple con el acuerdo (contrato) entre consumidor y proveedor. Esto es especialmente importante en arquitecturas de microservicios donde muchos servicios dependen unos de otros. Herramientas como Pact ayudan a asegurar que los cambios en un servicio no rompan otros.

Construyendo Tu Primer Plan de Testing de API

Al abordar una nueva API para testing, sigue este proceso sistematico:

Paso 1: Entender la Documentacion de la API

Lee la especificacion de la API (Swagger/OpenAPI, README o wiki). Anota:

  • Endpoints disponibles y sus propositos
  • Parametros requeridos y opcionales
  • Requisitos de autenticacion
  • Rate limits y restricciones

Paso 2: Identificar Escenarios de Test

Para cada endpoint, crea escenarios de test cubriendo:

Happy path:

  • Requests validos con todos los campos requeridos
  • Requests validos con campos opcionales incluidos
  • Diferentes valores validos para cada parametro

Testing negativo:

  • Campos requeridos faltantes
  • Tipos de datos invalidos (string donde se espera numero)
  • Valores limite (strings vacios, longitudes maximas, cero, numeros negativos)
  • Autenticacion invalida

Casos borde:

  • Caracteres especiales en strings (Unicode, emojis, tags HTML)
  • Payloads muy grandes
  • Requests concurrentes al mismo recurso
  • Requests con campos extra/desconocidos

Paso 3: Definir Resultados Esperados

Para cada escenario, documenta lo que la API deberia retornar:

  • Status code esperado
  • Estructura esperada del response body
  • Mensajes de error esperados para casos negativos
  • Efectos secundarios esperados (cambios en base de datos, eventos disparados)

Paso 4: Priorizar y Ejecutar

No todos los tests son igualmente importantes. Prioriza:

  1. Autenticacion y autorizacion
  2. Logica de negocio principal (operaciones CRUD)
  3. Validacion de input y manejo de errores
  4. Casos borde y condiciones limite
  5. Performance bajo carga

Ejercicio Practico

Usando cualquier REST API (recomendamos JSONPlaceholder — una API fake gratuita para testing), completa estas tareas:

  1. Envia un GET request a https://jsonplaceholder.typicode.com/posts/1 e identifica todos los campos en la respuesta
  2. Envia un POST request a https://jsonplaceholder.typicode.com/posts con un body JSON conteniendo title, body, y userId — nota el status code
  3. Envia un GET request a https://jsonplaceholder.typicode.com/posts/9999 (inexistente) — que status code obtienes?
  4. Documenta tus hallazgos en un reporte de test simple: endpoint, method, input, resultado esperado, resultado actual, pass/fail

Puedes usar las herramientas de desarrollo de tu navegador (tab Network), cURL desde la terminal, o descargar Postman (cubierto en la Leccion 6.4).

Puntos Clave

  • Las APIs son la capa de comunicacion entre sistemas de software y son criticas en la arquitectura de aplicaciones modernas
  • El testing de API se ubica en el medio de la piramide de testing, ofreciendo un balance de velocidad, estabilidad y cobertura
  • Cada interaccion con una API sigue un patron de request-response con methods, headers, status codes y body
  • Un plan de testing de API completo cubre happy paths, escenarios negativos, casos borde y seguridad
  • Comienza con testing manual para construir entendimiento, luego avanza a automatizacion para cobertura de regresion