Automatización de APIs que sobrevive a un backend real

Por qué la automatización de APIs se estanca siempre en los mismos cuatro puntos

Todos los equipos empiezan igual. Alguien escribe una petición contra un único endpoint, comprueba un código de estado y lo mete en CI. Funciona. Después la suite crece y llegan cuatro problemas, más o menos en el mismo orden para todo el mundo.

Los tokens caducan, así que la suite pasa por la mañana y falla al mediodía. Las respuestas contienen valores que necesita la siguiente petición, así que las pruebas o los fijan a mano en el código o se rompen. Algunos endpoints no se pueden llamar hasta que se ha creado otra cosa, así que el orden empieza a importar y nadie lo dejó escrito. Y cada ejecución deja registros atrás, así que la décima ejecución se comporta de forma distinta a la primera.

Nada de esto es exótico. Es la forma habitual de un backend real. La diferencia entre una suite que dura y una que se borra al cabo de un trimestre está en si estos cuatro puntos se diseñaron desde el principio o se descubrieron sobre la marcha.

Parte de lo que el servicio expone de verdad

Antes de todo eso necesitas un inventario. Escribir pruebas de memoria produce una suite que cubre los endpoints que se te ocurrieron, que suelen ser los que ya funcionaban.

Dos entradas te dan una imagen real. Un documento de especificación, como un archivo OpenAPI o un documento de requisitos de producto, te dice qué se supone que existe. Una pasada de descubrimiento sobre el servicio en ejecución te dice qué existe. La diferencia entre ambos ya es interesante por sí sola, y es mejor punto de partida para decidir la cobertura que una página en blanco. En TestSprite este primer paso es API Discovery, y acepta un PRD, documentación de la API u observación de llamadas en vivo.

A partir de ahí eliges los endpoints que merece la pena cubrir en lugar de aceptarlo todo. Un plan generado que incluye todas las rutas administrativas e internas es ruido, y el ruido es la forma en que las suites pierden a su público.

Problema uno: la autenticación (Auto-Authentication)

El enfoque ingenuo mete un token en una variable de entorno y lo renueva a mano cuando alguien se da cuenta de que hay fallos. Eso funciona hasta que la persona que lo sabe se va de vacaciones.

Lo que quieres en su lugar es que las credenciales pertenezcan al entorno y no a ninguna prueba concreta, y que el inicio de sesión se haga como parte de la ejecución. TestSprite lo llama Auto-Authentication: configuras el flujo de login una vez y se obtiene un token nuevo antes de cada ejecución. Dos principios importan más de lo que parece.

• Separa las credenciales de la prueba. Una prueba que contiene una contraseña no se puede compartir, no se puede apuntar a un segundo entorno y no se puede subir al repositorio. El caso debería decir «como usuario con sesión iniciada», no «como user@example.com con esta contraseña».

• Autentica una vez por ejecución siempre que el servicio lo permita. Cualquier servicio con un límite de intentos de login empezará a rechazar una suite que inicia sesión en cada caso, y esos rechazos son idénticos a errores del producto. Diagnosticar esa clase de falso fallo cuesta más tiempo que diseñar para evitarla.

Problema dos: valores que solo existen en tiempo de ejecución (Dynamic Variables)

Una llamada de creación devuelve un identificador. Las llamadas de actualización y de borrado lo necesitan. Si el identificador se pega dentro de la prueba, la prueba es válida exactamente una vez.

La solución es capturar el valor de la respuesta y referenciarlo después, para que la suite arrastre los datos hacia delante en lugar de darlos por supuestos. En la práctica eso significa que una prueba no dice DELETE /orders/8412. Dice: borra el pedido que creó esta ejecución, sea cual sea el identificador que le haya tocado.

Escrito así suena obvio y es la razón más común de que una suite que pasaba el mes pasado falle hoy. El mecanismo tiene nombre en TestSprite, Dynamic Variables: capturar un valor de una respuesta e inyectarlo en la siguiente petición, con las conexiones deducidas en lugar de mantenidas a mano.

Problema tres: endpoints que dependen unos de otros (Dependency Chains)

No puedes añadir un artículo a un carrito que no existe. No puedes finalizar la compra de un carrito sin artículos. La cobertura real de una API no es una lista plana de llamadas, es un grafo.

Cuando ese grafo es implícito, salen dos cosas mal. Las pruebas se ejecutan en un orden que por casualidad funciona en una máquina y no en otra, y un único fallo temprano produce veinte fallos posteriores que parecen errores distintos.

Hacer explícitas las dependencias arregla ambas cosas. Cada caso declara qué necesita y qué produce, la ejecución deduce de ahí un orden seguro, y cuando algo falla obtienes un fallo con diecinueve casos omitidos en lugar de veinte filas rojas que revisar. Esta es la diferencia entre Endpoint Tests, que cubren una ruta cada vez, e Integration Tests, que son cadenas de varios pasos en las que una respuesta alimenta la siguiente.

Problema cuatro: los datos que dejas atrás (Auto-Cleanup)

Una suite que crea registros y nunca los elimina se degrada a su propio ritmo. Las listas se alargan, las aserciones de paginación se desvían, empiezan a saltar las restricciones de unicidad y al final alguien vacía una tabla a mano un viernes.

La limpieza tiene que formar parte de la ejecución, ligada a los recursos que creó esa ejecución concreta. Limpiar por patrón, como borrar todo aquello cuyo nombre empiece por test-, funciona hasta que dos ejecuciones se solapan o hasta que alguien del negocio crea un registro con un nombre desafortunado. Auto-Cleanup elimina los registros que creó una ejecución cuando esa ejecución termina, que es la versión que sobrevive a la concurrencia.

Cómo es, de principio a fin, una automatización de APIs que funciona

Juntando las cuatro piezas, una configuración que aguanta un año se parece a esto.

Llevarlo al pipeline

Una suite de API que se ejecuta cuando alguien se acuerda es una suite que se ejecuta antes de las releases y no antes de los merges, que es el extremo equivocado. Hay dos formas de entrar, y la elección tiene que ver con quién quieres que sea dueño del disparador.

Conviene saberlo antes de elegir: hay dos superficies y resuelven esto de forma distinta. El portal web es el camino de generar y mantener, donde el descubrimiento, el cableado de dependencias y la limpieza se deducen por ti. El CLI es el camino de trae tu propio código: allí las pruebas de backend son Python que escribes tú, declaras tú mismo qué necesita y qué produce cada una, y el teardown es una prueba que marcas como tal. Los mismos cuatro problemas, distinto reparto del trabajo. Los equipos que quieren que la suite viva en su repositorio eligen la segunda opción deliberadamente.

Dos rutas, y la elección tiene que ver con dónde quieres que viva la configuración.

Dos rutas, y la elección tiene que ver en realidad con quién es dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu build ya emite. Añadir un paso de GitHub Actions pone la comprobación en el repositorio, donde se revisa igual que el resto del build; los comandos actuales están en el repositorio del CLI.

Dos límites honestos

Esto es verificación funcional. Los planes generados sí incluyen casos de valores límite y de autorización, así que una ejecución te dirá si se rechaza un valor fuera de rango y si se deniega una petición sin autenticar. Eso no es lo mismo que pruebas de carga o escaneo de vulnerabilidades. No te dirá cómo se comporta el servicio bajo concurrencia sostenida, y no es un escáner. Son instrumentos distintos y fingir lo contrario te hará perder la tarde.

Tampoco va a salvar una API sin especificación y sin convenciones consistentes. El descubrimiento puede enumerar endpoints, pero decidir qué significa correcto para cada uno sigue siendo un juicio, y alguien de tu equipo tiene que hacerlo. El trabajo es menor que escribir la suite a mano, y no es cero.

Cómo aborda TestSprite los cuatro problemas

Los cuatro puntos de fallo de esta página no son accidentales en las pruebas de API, así que se resuelven como producto en lugar de dejarse en manos de tu infraestructura. Auto-Authentication toma el flujo de login una vez y obtiene un token nuevo antes de cada ejecución. Dynamic Variables lleva un valor de una respuesta a la siguiente petición. Dependency Chains deduce un orden de ejecución seguro a partir de lo que cada caso necesita y produce. Auto-Cleanup elimina exactamente los registros que creó una ejecución, que es la versión que sobrevive a la ejecución en paralelo.

La cobertura también viene de otro sitio. API Discovery enumera lo que el servicio en ejecución expone realmente, plan generation propone casos en las categorías funcional, de esquema, de autorización, de manejo de errores y de valores límite, y tú los refinas en lenguaje natural. El resultado incluye los casos negativos que nadie escribe al final de un sprint.

Dónde te deja eso: una suite que sigue funcionando a medida que la API cambia, sin un conftest ni un directorio de soporte que solo entiende una persona. La capacidad de carga y el escaneo de vulnerabilidades siguen siendo instrumentos aparte.

Cada uno de los cuatro tiene su propia página en la documentación de pruebas de API si quieres la mecánica en lugar del razonamiento.