Respuesta.

El aislamiento de las pruebas con servicios externos es un requisito imprescindible para una automatización fiable.

Historia de la cuestión: Los primeros sistemas de automatización "luchaban" contra APIs externas y bases de datos que a menudo estaban o bien no disponibles, o bien devolvían datos imprevistos. Sin aislamiento de las pruebas automatizadas, no es posible reproducir el resultado: parpadeo, caída debido a problemas externos, fallos aleatorios.

Problema:

Los servicios externos suelen ser inestables: pueden cambiar el contrato, puede que no haya datos o la prueba cause efectos secundarios.
Necesidad de controlar ("fijar") la respuesta externa para la previsibilidad del resultado.
Respuestas lentas y la imposibilidad de reproducir escenarios localmente o en CI.

Solución:

Uso de "mocks" y "stubs" — sustitutos locales que simulan respuestas de APIs externas. Son populares WireMock (Java), httpmock (Python), MockServer, TestContainers.
Emulación de la base de datos con soluciones en memoria o fixtures que se limpian y se vuelven a llenar antes de cada prueba.

Extracción de ID de datos de prueba a variables, para que las pruebas puedan ejecutarse en paralelo y no "pisarse" entre sí.

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # En las pruebas reales, la respuesta será devuelta por el mock server
    # Aquí la llamada a requests.post y aserción ...

Características clave:

Uso de servidores mock para simular dependencias externas.
Limpieza del estado: limpieza de datos antes/después de la prueba (setup/teardown).
Aislamiento de identificadores de entidades de prueba.

Preguntas capciosas.

¿Es obligatorio realizar pruebas de integración a través de servicios reales en cada ejecución?

No. Regularmente se pueden utilizar mocks/stubs, y las pruebas de integración ejecutarse por separado, menos frecuentemente y bajo control.

¿Las pruebas con una API externa real siempre ofrecerán un resultado más fiable?

No. Por el contrario, son menos estables, pueden fallar debido a cambios en el lado del socio. Las pruebas de parpadeo constantes empeoran la calidad de la canalización.

¿Se pueden utilizar los mismos datos de prueba para pruebas automatizadas paralelas con servicios externos?

No. Esto puede llevar a colisiones, "carreras" y falta de estabilidad. Los identificadores y el estado deben ser únicos por prueba/hilo.

Errores típicos y anti-patrones

No hay limpieza o aislamiento de los datos de prueba.
Uso de API real incluso para pruebas unitarias.
Acortamiento injustificado del tiempo de espera (timeout), lo que lleva a falsos fallos.
No considerar cambios en la API externa (rompiendo las pruebas para todos a la vez).

Ejemplo de la vida

Caso negativo

En la empresa decidieron, para ser más rápidos, ejecutar todas las pruebas automatizadas en APIs externas reales (puerta de enlace de pago). Varias veces las pruebas fueron bloqueadas, se superaron los límites, había que restaurar el acceso, los datos "fluyeron" a informes reales, aparecieron falsas alarmas.

Pros:

Integración rápida con el servicio real.

Contras:

Cambios en el lado del operador rompían las pruebas, gastos de tiempo y dinero, basura de prueba en "servicios de producción", dificultad de reproducción.

Caso positivo

Configurar MockServer y una base de datos in-memory ficticia. Antes de cada prueba, el estado se reiniciaba, los datos eran únicos. Las pruebas de integración reales se realizaban separadamente y con menor frecuencia.