Por qué las pruebas de integración de API necesitan un grafo explícito
| El orden se vuelve accidental | Las pruebas pasan en el orden que el runner eligió por casualidad y fallan en otra máquina. Alguien agrega un plugin de ordenamiento y el problema se vuelve permanente. |
| Un fallo parece veinte | Falla la creación, falla todo lo que viene después y te queda una pantalla en rojo. Encontrar el primer fallo real se convierte en el trabajo. |
| El paralelismo no es seguro | Sin saber qué depende de qué, no puedes ejecutar nada de forma concurrente con seguridad. Así que las suites se quedan en serie y lentas. |
Hacerlo explícito
La solución es que cada prueba declare qué necesita y qué produce. Cuando eso existe, el runner deriva un orden seguro, las ramas independientes se ejecutan en paralelo y un fallo marca a sus dependientes como omitidos en lugar de fallidos. Veinte filas rojas se convierten en un fallo y diecinueve omisiones, que es una experiencia de depuración completamente distinta.
Esta es la diferencia entre Endpoint Tests, que cubren una ruta a la vez, e Integration Tests, que son cadenas de varios pasos donde una respuesta alimenta la siguiente.
El problema de pasar valores
Una llamada de creación devuelve un identificador que los pasos posteriores necesitan. Si lo escribes fijo en el código, la prueba funciona exactamente una vez. Si lo capturas, la cadena arrastra los datos hacia adelante como corresponde. Escrito así suena trivial, y es la razón más común de que una suite que pasaba el mes pasado falle hoy.
La limpieza dentro de una cadena
Las pruebas de integración crean más estado que las pruebas de endpoint, y lo crean en un orden de dependencias que el teardown tiene que respetar. No puedes eliminar al cliente antes que el pedido. Una limpieza ligada a lo que creó cada ejecución, en orden inverso de dependencias, es la única versión que sobrevive a la concurrencia.
Cuatro cosas deciden si una suite de API sobrevive a su primer año: sesiones que caducan, valores que solo existen en tiempo de ejecución, llamadas que dependen unas de otras y registros que nadie limpia. TestSprite resuelve esto con Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, descritos en la documentación de pruebas de API.
Qué hacer cuando una cadena falla en el paso cuatro
El valor de declarar dependencias se ve con más claridad en el aspecto que tiene un fallo, y vale la pena conocer el orden de lectura.
Primero, comprueba si el fallo está en el paso o en sus entradas. Un paso que recibió el identificador equivocado falló porque algo anterior produjo algo incorrecto, y arreglar el paso sería arreglar el síntoma.
Segundo, comprueba si falla partiendo de un estado limpio. Una cadena que funciona una vez y falla al volver a ejecutarla te está diciendo que la limpieza no ocurrió, que es un error distinto del que estás mirando y a menudo el más importante.
Tercero, y solo entonces, mira el endpoint en sí. La mayoría de las veces la información interesante estaba en las dos primeras comprobaciones, y por eso una lista plana de filas rojas cuesta mucho más de depurar que un grafo con un fallo y diecinueve omisiones.
Mantén las cadenas cortas
Una cadena de doce pasos que falla en el paso nueve es difícil de diagnosticar y lenta de volver a ejecutar. De tres a cinco pasos que cubran una sola intención del usuario es el tamaño que sigue siendo útil. Las cadenas largas suelen significar que se fusionaron dos recorridos.
Para empezar
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si prefieres no instalar nada, el dashboard hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.
Conecta el repositorio desde el dashboard y las ejecuciones arrancan desde el despliegue que ya generas, o bien agrega un paso a tu propio workflow.
Cómo TestSprite hace explícito el grafo
Cada caso declara qué necesita y qué produce, y Dependency Chains deriva de ahí un orden de ejecución seguro. Las ramas independientes se ejecutan en paralelo y, cuando algo falla, sus dependientes se marcan como omitidos en lugar de fallidos, así que veinte filas rojas se convierten en un fallo y diecinueve omisiones.
Dynamic Variables se encarga de pasar los valores, de modo que una cadena lleva el identificador que devolvió una llamada de creación y no un número que alguien pegó. Auto-Cleanup elimina lo que creó cada ejecución, en orden inverso de dependencias, que es lo que hace seguras las ejecuciones concurrentes.
El beneficio aparece la primera vez que se rompe una cadena. Obtienes un único fallo que identifica el punto de divergencia en lugar de una pantalla en rojo que hay que leer entera, y esa es la diferencia entre un diagnóstico de cinco minutos y una tarde.
¿En qué se diferencia esto de las pruebas end-to-end?
End-to-end suele significar a través de la interfaz. Las pruebas de integración de API recorren los mismos trayectos en la capa de servicio, lo que es más rápido y más preciso sobre dónde ocurrió el fallo.
¿Las pruebas de integración deberían usar dependencias reales?
Para las pruebas de integración, sí, de eso se trata. Simular con un mock aquello con lo que te estás integrando responde a una pregunta distinta.
¿Cómo manejamos los datos de prueba entre pasos?
Captura lo que produce cada paso y pásalo al siguiente. Los datos precargados compartidos son cómodos hasta que dos cadenas tocan el mismo registro.
¿Y los servicios de terceros dentro de una cadena?
Usa su sandbox cuando exista. Cuando no exista, aísla ese paso y acepta que la cadena tiene un límite.
¿Cuántas pruebas de integración necesitamos?
Una por cada recorrido de usuario que importe, no una por cada combinación de endpoints. Las combinaciones son infinitas y los recorridos no.
Declara el grafo o depúralo para siempre.
Las pruebas de integración de API van de secuencias, y las secuencias tienen un grafo de dependencias. Declarar qué necesita y qué produce cada prueba te da un orden seguro, paralelismo y fallos legibles. Captura los valores en lugar de escribirlos fijos en el código, y mantén las cadenas cortas.