Skip to content
IRC-CodingIRC-Coding
API TestingUnit TestsIntegration TestsContract TestsEstrategia de pruebasConsumer Driven Contracts

API Testing: Unit, Integration y Contract Tests

Domina API Testing con Unit Tests, Integration Tests, Contract Tests y mejores prácticas para APIs confiables y mantenibles.

S

schutzgeist

7 min read
API Testing: Unit, Integration y Contract Tests

API Testing: Unit, Integración y Contract Tests

Las APIs confiables requieren una estrategia de pruebas bien pensada que combine unit tests, tests de integración y contract tests para detectar errores temprano y proteger los contratos de interfaz.

Descripción compacta

API Testing abarca todas las actividades de prueba que garantizan la corrección, seguridad, rendimiento y estabilidad de una API. Los unit tests validan funciones aisladas, controllers o handlers sin dependencias externas. Los tests de integración verifican la colaboración entre múltiples componentes, como la API, la base de datos y servicios externos. Los contract tests aseguran que el proveedor y el consumidor de una API respeten el mismo contrato, por ejemplo mediante OpenAPI o Pact. Una buena estrategia de pruebas cubre la API en diferentes niveles, está automatizada y se ejecuta en la pipeline de Continuous Integration. El objetivo es encontrar errores temprano, evitar regresiones y documentar y proteger de forma confiable el contrato entre la API y los clientes.

Componentes clave

Unit Tests para APIs

Los unit tests validan pequeñas unidades aisladas de la API, como handlers, controllers o lógica de validación. Las dependencias externas como bases de datos o HTTP clients se reemplazan con mocks o stubs. Los unit tests son rápidos y ofrecen retroalimentación inmediata ante cambios.

Tests de integración

Los tests de integración verifican cómo la API colabora con dependencias reales o containerizadas. Esto incluye acceso a bases de datos, message queues, APIs externas y servicios de autenticación. Testcontainers permite iniciar bases de datos u otros servicios en entornos de prueba.

Tests End-to-End

Los tests End-to-End simulan la API desde la perspectiva del cliente. Envían solicitudes HTTP reales y validan la respuesta completa. Herramientas como Postman, REST Assured o Supertest se utilizan frecuentemente. Los tests E2E son más lentos pero cubren el stack completo.

Contract Tests

Los contract tests verifican que la API y el cliente respeten el contrato acordado. El contrato se define mediante OpenAPI, JSON Schema o frameworks como Pact. Los Consumer Driven Contracts permiten que los consumidores comuniquen sus expectativas al proveedor.

Consumer Driven Contracts

En Consumer Driven Contracts, los clientes documentan sus expectativas como un contrato. El proveedor debe cumplir con este contrato. Pact es un framework popular para este enfoque. Evita que cambios en la API rompan inadvertidamente a los clientes.

Pirámide de pruebas

La pirámide de pruebas establece que debes tener muchos unit tests rápidos, menos tests de integración y solo algunos tests E2E lentos. Los contract tests complementan la pirámide entre integración y unit tests. Ayudan a validar contratos de interfaz de forma eficiente.

Datos de prueba y fixtures

Los datos de prueba deben ser reproducibles e aislados. Los fixtures, factories o métodos de setup generan los datos necesarios antes de cada test. Los tests de base de datos deben utilizar transacciones o bases de datos nuevas para aislar estados entre tests.

Mocking y Stubbing

Mocking reemplaza dependencias externas con objetos controlados. Stubbing proporciona respuestas predefinidas. Ambas técnicas son importantes para unit tests, pero no para tests de integración donde se utilizan dependencias reales.

Fuzzing y tests negativos

Los tests negativos verifican cómo la API maneja entradas inválidas, campos faltantes o tipos de datos inesperados. Fuzzing genera automáticamente muchas entradas aleatorias o semi-aleatorias para descubrir vulnerabilidades.

Tests de rendimiento

Los tests de rendimiento validan tiempos de respuesta, throughput y comportamiento bajo carga. Se utilizan herramientas como k6, JMeter o Gatling. Complementan los tests funcionales e son importantes para APIs con altos requisitos de disponibilidad y escalabilidad.

Integración con CI/CD

Los tests de API deben ejecutarse automáticamente en la pipeline de Continuous Integration. Los unit tests se ejecutan en cada build, los tests de integración antes del merge, los contract tests ante cambios en la API y los tests E2E antes del deployment. Los errores detienen el build tempranamente.

Ejemplo práctico

Un equipo Node.js prueba una API de pedidos en todos los niveles.

Unit test para validación de un pedido:

describe('Order validation', () => {
  test('rejects negative quantity', () => {
    const result = validateOrder({ customerId: 1, items: [{ productId: 5, quantity: -1 }] });
    expect(result.valid).toBe(false);
    expect(result.errors).toContain('quantity must be positive');
  });
});

Test de integración con Testcontainers:

describe('POST /orders', () => {
  test('creates an order and persists it', async () => {
    const response = await request(app)
      .post('/orders')
      .send({ customerId: 1, items: [{ productId: 5, quantity: 2 }] })
      .expect(201);

    expect(response.body.id).toBeDefined();
    expect(response.body.status).toBe('created');

    const order = await db.query('SELECT * FROM orders WHERE id = ?', [response.body.id]);
    expect(order).toHaveLength(1);
  });
});

Contract test con Pact:

const pact = new Pact({
  consumer: 'web-shop',
  provider: 'order-service',
});

await pact.addInteraction({
  state: 'order can be created',
  uponReceiving: 'a request to create an order',
  withRequest: {
    method: 'POST',
    path: '/orders',
    body: { customerId: 1, items: [{ productId: 5, quantity: 2 }] }
  },
  willRespondWith: {
    status: 201,
    body: { id: 1, status: 'created' }
  }
});

La combinación de estos tres niveles asegura que la API se pruebe temprano y de forma completa.

FAQ: API Testing

1. ¿Qué es API Testing?

API Testing abarca todas las actividades de prueba que garantizan la corrección, seguridad, rendimiento y estabilidad de una API. Incluye unit tests, tests de integración, contract tests y tests End-to-End.

2. ¿Qué es un unit test para APIs?

Un unit test para APIs valida funciones aisladas como handlers, controllers o lógica de validación. Las dependencias externas se reemplazan con mocks.

3. ¿Qué es un test de integración?

Un test de integración verifica la colaboración entre múltiples componentes, como la API, la base de datos, servicios externos o message queues. Se utilizan dependencias reales o containerizadas.

4. ¿Qué es un contract test?

Un contract test asegura que el proveedor y el consumidor de una API respeten el mismo contrato. El contrato se define mediante OpenAPI, JSON Schema o Pact.

5. ¿Qué es Consumer Driven Contract Testing?

Consumer Driven Contract Testing significa que los clientes definen sus expectativas como un contrato. El proveedor debe cumplir estos contratos para evitar cambios que rompan inadvertidamente a los consumidores.

6. ¿Qué es Pact?

Pact es un framework para Consumer Driven Contract Testing. Genera contratos a partir de tests del consumidor y los verifica posteriormente contra el proveedor.

7. ¿Qué es la pirámide de pruebas?

La pirámide de pruebas establece que debe haber muchos unit tests rápidos, menos tests de integración y solo algunos tests E2E lentos. Los contract tests complementan la pirámide entre unit e integración.

8. ¿Qué es Mocking?

Mocking reemplaza dependencias externas con objetos controlados que proporcionan respuestas predefinidas. Se utiliza principalmente en unit tests.

9. ¿Qué son Testcontainers?

Testcontainers son dependencias containerizadas como bases de datos, message queues o caches que se inician durante las pruebas. Permiten tests de integración realistas sin infraestructura manual.

10. ¿Qué es un test End-to-End?

Un test End-to-End envía solicitudes HTTP reales a la API y valida la respuesta completa. Cubre el stack entero pero es más lento y requiere más mantenimiento que los unit tests.

11. ¿Qué son tests negativos?

Los tests negativos verifican cómo la API maneja entradas inválidas o incompletas. Aseguran que los errores se tratén correctamente.

12. ¿Qué es Fuzzing?

Fuzzing genera automáticamente muchas entradas aleatorias o semi-aleatorias para descubrir vulnerabilidades, fallos o comportamientos inesperados en la API.

13. ¿Qué son tests de rendimiento para APIs?

Los tests de rendimiento validan tiempos de respuesta, throughput y comportamiento bajo carga. Herramientas como k6, JMeter o Gatling ayudan a identificar cuellos de botella.

14. ¿Por qué los tests de API deben ejecutarse en CI/CD?

Los tests automatizados en CI/CD detectan errores temprano antes de llegar a producción. Aseguran refactorings, previenen regresiones y mantienen una calidad consistente.

15. ¿Cuáles son las mejores prácticas para API Testing?

Las mejores prácticas incluyen una pirámide de pruebas equilibrada, datos de prueba aislados y reproducibles, responsabilidades claras en cada nivel de pruebas, contract tests para interfaces, ejecución automatizada en CI/CD y tests de rendimiento regulares.

Continúa en el camino de aprendizaje de APIs

El próximo artículo en el camino de aprendizaje de APIs trata sobre implementación de Rate Limiting en APIs — cómo implementar Rate Limiting en APIs usando Token Bucket, Sliding Window y Redis.

Referencias

  1. https://martinfowler.com/articles/consumerDrivenContracts.html
  2. https://docs.pact.io/
  3. https://www.testcontainers.org/

Recomendaciones de libros sobre testing y diseño de APIs

Si deseas profundizar en testing de APIs, automatización de pruebas y calidad de software, te recomendamos estos libros:

Keine Bücher für Kategorie "api-development" gefunden.

Volver al blog
Share:

Entradas relacionadas