El veredicto, primero
-
Elige REST Assured si eres un equipo JVM que quiere las pruebas de API en el mismo lenguaje, la misma compilación y el mismo proceso de revisión que el propio servicio.
-
Elige TestSprite si el cuello de botella es la amplitud de la cobertura y los cuatro problemas de estado, y no la sintaxis de las aserciones.
-
Usa ambos si tienes una suite de REST Assured que alguien mantiene. Conserva las pruebas que especificaste de forma deliberada y añade amplitud generada a su alrededor.
Cara a cara
| Dimensión | REST Assured | TestSprite |
|---|---|---|
| Qué es | Un DSL de Java para lanzar peticiones y hacer aserciones sobre las respuestas | Un servicio que genera, ejecuta y mantiene la cobertura de API |
| Quién escribe las pruebas | Tus ingenieros, en Java o Kotlin | Se genera a partir de una especificación o de un descubrimiento, y se refina en lenguaje natural |
| Legibilidad | Excelente. given / when / then se lee como una frase | Los casos se describen en lenguaje sencillo |
| Gestión de sesiones | Un filtro o una especificación base que escribes tú | Auto-Authentication, configurado una sola vez |
| Valores entre llamadas | Los extraes a un campo y los pasas tú mismo | Dynamic Variables |
| Orden y limpieza | La ordenación de JUnit más el teardown que mantienes tú | Orden derivado y Auto-Cleanup |
| Mejor encaje | Equipos JVM con capacidad para escribir y mantener | Equipos que necesitan amplitud sin una función de QA dedicada |
Cuándo REST Assured es la elección correcta
Pruebas como parte de la base de código. Mismo lenguaje, misma revisión, misma compilación. Para algunos equipos eso es innegociable, y es una postura razonable.
Aserciones personalizadas complejas. Cuando la corrección exige lógica real y no una comparación de campos, un lenguaje completo es la herramienta adecuada.
Inversión previa en la JVM. Fixtures compartidos, objetos de dominio y herramientas de compilación que ya tienes.
Lo que sigue siendo tu trabajo
Las sesiones caducan, los identificadores tienen que viajar entre llamadas, algunos endpoints no se pueden llamar antes que otros y cada ejecución deja registros atrás. REST Assured no opina sobre nada de esto, lo cual es correcto para un DSL y significa que las cuatro cosas acaban en tu infraestructura de pruebas.
También hay un problema con la forma de la cobertura: una suite escrita a mano cubre lo que alguien recordó, y las rutas de error y los valores límite que rompen en producción son justo los que nadie escribe al final de un sprint. Las cuatro mecánicas se describen en la documentación sobre pruebas de API.
El problema del grafo de fixtures, en concreto
El punto en el que una suite de REST Assured empieza a costar más de lo que devuelve suele verse en los fixtures de JUnit antes que en las pruebas.
Una prueba necesita un pedido. Un pedido necesita un cliente y un producto. El cliente necesita una cuenta con un nivel determinado. Expresado como fixtures, eso es un árbol pequeño, y JUnit lo construirá sin problema. Luego una segunda prueba necesita el mismo cliente pero un producto distinto, y una tercera necesita dos clientes. Ahora el árbol es un grafo, los fixtures empiezan a recibir parámetros y el código de preparación es más largo que las aserciones.
Nada de esto es un problema de lenguaje ni se resuelve con una mejor ergonomía del DSL. Es el costo de expresar un grafo de dependencias en un framework cuyo modelo es un árbol, y es exactamente lo que elimina una capa creada para ello.
Usar ambos
Conserva REST Assured para los casos que especificaste de forma deliberada y para las aserciones que necesitan lógica real. Deja que la cobertura generada aporte amplitud sobre toda la superficie. Ambos se ejecutan desde el mismo pipeline.
Si estás evaluando, rompe algo a propósito
Introduce una regresión real, como un botón de guardar que ya no persiste los datos, y observa qué informa cada herramienta. Tres preguntas: ¿falla?, ¿el fallo nombra la divergencia real?, y ¿podría la persona o el agente que va a arreglarlo partir de esa salida sin reconstruir la historia? Una herramienta que informa de un resultado correcto en una ejecución que nunca llegó a sus aserciones ha fallado la única prueba que importa.
Si el pipeline es de otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu compilación informa de que la nueva versión está en producción. Si prefieres que la comprobación se vea en el repositorio, un paso de GitHub Actions hace eso. Consulta el repositorio de la CLI.
Qué resuelve TestSprite a nivel de suite
Los cuatro problemas que quedan fuera de cualquier DSL. Auto-Authentication para la duración de la sesión, Dynamic Variables para los valores capturados entre llamadas, Dependency Chains para que el orden se derive en lugar de codificarse en el anidamiento de fixtures, y Auto-Cleanup ligado a lo que creó cada ejecución.
La cobertura se genera a partir de tu especificación y de una pasada de descubrimiento sobre el servicio en ejecución, y luego se refina en lenguaje sencillo, lo que significa que los valores límite y las rutas de error existen sin que nadie los escriba a las once de la noche.
Con lo que se queda tu equipo JVM: REST Assured para los casos que especificaste de forma deliberada y para las aserciones que necesitan lógica real, y ningún grafo de fixtures que mantener por debajo. Ambos se ejecutan desde el mismo pipeline.
¿Se sigue manteniendo REST Assured?
Sigue siendo muy usado en los equipos JVM. Aquí el argumento va sobre dónde se acumula el costo a nivel de suite, no sobre la biblioteca.
¿Podemos conservar nuestras pruebas actuales?
Sí, y deberías hacerlo si hay gente que las mantiene. Añade cobertura en otra capa en lugar de migrar.
¿Y el soporte de pruebas de Spring Boot?
Excelente para las pruebas de integración dentro del contexto de la aplicación. Aquí hablamos de probar el servicio desplegado desde fuera, que es una pregunta distinta.
¿La cobertura generada entiende nuestro dominio?
Parte de tu especificación y del servicio en ejecución. Las reglas propias del dominio se añaden refinando los casos, que es donde tu conocimiento sigue importando.
¿Cómo evitamos duplicar cobertura?
Conserva las pruebas escritas a mano para lo que especificaste a propósito, orienta la cobertura generada hacia la amplitud y asume que un poco de solapamiento sale barato.
Aserciones excelentes. El costo a nivel de suite sigue siendo tuyo.
REST Assured hace que escribir pruebas de API individuales en Java sea un placer. Las sesiones, los valores capturados, el orden y la limpieza siguen siendo tu infraestructura, y la cobertura sigue limitada a lo que alguien recordó. Consérvalo para los casos deliberados y añade amplitud generada a su lado.