Respuesta.

La automatización de pruebas de REST API es una de las formas más rápidas y efectivas de controlar la lógica empresarial de una aplicación del servidor, permitiendo validar la corrección de las respuestas sin UI.

Historia de la pregunta: Anteriormente, la atención principal en las pruebas se centraba en la interfaz de usuario, sin embargo, con el desarrollo de arquitecturas de microservicios y el aumento de la complejidad de las interacciones entre componentes, se volvió importante probar la interacción "a través de API".

Problema: El REST API puede cambiar con frecuencia: cambian los esquemas, parámetros, formatos de solicitudes y respuestas. Además, no son raras las dependencias de servicios externos, lo que complica la creación de pruebas aisladas y confiables. En un gran proyecto, el número de endpoints se cuenta por cientos.

Solución: Se recomienda usar bibliotecas especializadas (RestAssured, Postman/Newman, clientes HTTP), modelar los escenarios de prueba de acuerdo con los requisitos del negocio y aislar al máximo el entorno de prueba mediante mocks/stubs. También es útil generar datos de prueba automáticamente y utilizar validación según esquemas (por ejemplo, JSON Schema).

Características clave:

Registro explícito de respuestas de referencia y contratos de API
Uso de mocks y dobles de prueba para dependencias externas
Construcción de escenarios teniendo en cuenta caminos positivos y negativos (pruebas de límite, casos de error)

Preguntas trampa.

¿Se puede probar el REST API solo a nivel de contenido de respuesta?

No, es necesario validar el contrato completo: códigos de respuesta, encabezados, estructura e incluso tiempo de respuesta.

¿Es suficiente al automatizar REST verificar solo el "happy path" — escenarios positivos?

No, es obligatorio probar estados límite, validación de datos, manejo de errores y escenarios no estándar ("edge cases").

¿Es necesario crear un entorno separado para la automatización?

Preferiblemente, para minimizar la influencia de las pruebas en datos reales y obtener resultados estables. Las pruebas pueden crear y modificar recursos, lo que no siempre es aceptable en un entorno en producción.

Errores típicos y anti-patrones

Las pruebas almacenan datos "hardcode"
No hay verificación de escenarios negativos
No hay un teardown correcto, las pruebas ensucian el entorno

Ejemplo de la vida

Caso negativo

Todas las pruebas acceden a la API de producción, trabajan sobre los mismos recursos y no limpian los datos. Una prueba puede "romper" el estado, las demás fallan inmediatamente.

Ventajas:

Mínimos esfuerzos en infraestructura

Desventajas:

Fallos regulares
Dependencia del estado de los datos
Peligro para el entorno de producción

Caso positivo

Se crea un entorno separado, las pruebas utilizan servicios simulados para pruebas de integración y datos de prueba aislados, el teardown después de cada prueba devuelve el entorno a su estado original.