Por qué surge el tema de las pruebas de API con Selenium
Hay tres razones, y solo una es buena.
La suite ya existe. Ya hay un job de Selenium en CI, la gente sabe ejecutarlo y añadir ahí las verificaciones de API es el camino de menor resistencia. Es comprensible, y es una razón organizativa antes que técnica.
El flujo abarca ambos. Enviar un formulario y luego confirmar que el registro que creó la API es correcto. Este caso sí es legítimo y es el que vale la pena diseñar con intención.
Preparación y limpieza. Crear los datos de prueba a través de la API porque hacerlo por la interfaz es lento. Tiene sentido, aunque es infraestructura y no pruebas.
Lo que cuesta
| Retroalimentación lenta | El arranque del navegador domina una verificación que podría haber sido una petición. Una suite que tarda veinte minutos se ejecuta con menos frecuencia, y esa es la verdadera pérdida. |
| Fallos confusos | Cuando falla una prueba combinada, tienes que averiguar si lo que se rompió fue la interfaz o la API. Con suites separadas obtienes esa respuesta gratis. |
| Cobertura moldeada por la UI | Terminas cubriendo los endpoints que la interfaz llama por casualidad, que son una fracción de la superficie. Los códigos de error y los parámetros límite nunca se ejercitan. |
La división que sí funciona
Reserva Selenium para lo que solo un navegador puede responder: si funciona el flujo que ve el usuario. Cubre la API en su propio nivel, donde una verificación es una petición y no la carga de una página. Usa la API desde la suite de Selenium solo para la preparación y la limpieza, donde lo que importa es la velocidad y no hay ninguna aserción de por medio.
El único caso realmente transversal, enviar un formulario y verificar qué guardó el backend, conviene escribirlo de forma deliberada y no por accidente. Son pocas pruebas y justifican su costo.
Lo que tiene que resolver una capa de API independiente
Cuatro cosas deciden si una suite de API sobrevive a su primer año, sea cual sea la herramienta que uses: las sesiones que expiran, los valores que solo existen en tiempo de ejecución, las llamadas que dependen unas de otras y los registros que nadie limpia. TestSprite las llama Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup, y la documentación de pruebas de API explica su funcionamiento.
Resolver bien estas cuatro cosas es lo que separa una suite que perdura de una que se borra a los dos trimestres, y es mucho más fácil hacerlo en el nivel de la API que atornillado a una suite de navegador.
El caso de la preparación, bien hecho
Usar la API para crear datos de prueba para una prueba de navegador es el único punto donde ambos encajan de verdad, y conviene hacerlo de forma deliberada y no por accidente.
La regla que mantiene esto limpio es que las llamadas de preparación nunca hacen aserciones. Su trabajo es dejar el sistema en un estado conocido lo más rápido posible, y si una de ellas falla, la prueba debería terminar en error y no en fallo, porque un dato de prueba que no se creó es un problema de infraestructura y no un defecto del producto. Mezclar ambas cosas produce una suite en la que la mitad del rojo es ruido.
La segunda regla es que todo lo que creó la preparación lo elimina la limpieza, vinculado a esa prueba y no identificado por nombre. Las suites de navegador acumulan datos más rápido de lo que cualquiera espera, y una vista de lista que se vuelve más lenta cada semana suele ser una limpieza que nunca se escribió.
Ejecutar ambas
Ninguna de las dos suites necesita saber de la otra. Selenium se ejecuta en tu job de CI igual que hoy, y la cobertura de API corre junto a ella.
Si el pipeline pertenece a 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 build reporta que la nueva versión está publicada. Si prefieres que la verificación se vea en el repositorio, un paso de GitHub Actions hace eso. Consulta el repositorio del CLI.
Lo que cubre TestSprite en el nivel de la API
TestSprite se encarga de la capa de API independiente para que no tengas que atornillarla a una suite de navegador. API Discovery enumera lo que expone el servicio en ejecución, Plan Generation propone casos en las categorías funcional, de esquema, de autorización, de manejo de errores y de límites, y tú los refinas en lenguaje sencillo.
Los cuatro problemas de estado vienen como producto y no como infraestructura tuya: Auto-Authentication mantiene vivas las sesiones, Dynamic Variables llevan valores de una llamada a otra, Dependency Chains deducen el orden de ejecución y Auto-Cleanup elimina lo que creó una ejecución. Esas son las cosas que hacen difícil mantener viva una suite de API, y son mucho más fáciles de resolver en el nivel de la API que dentro de un runner de navegador.
Tu suite de Selenium se queda donde está, cubriendo lo que solo un navegador puede responder. Ambas se ejecutan desde el mismo pipeline.
¿Puede Selenium enviar peticiones HTTP directamente?
A través de los bindings del lenguaje, sí, porque al final estás escribiendo código. La pregunta es si debería haber una sesión de navegador de por medio, y para una verificación puramente de API la respuesta suele ser no.
¿Deberíamos migrar nuestra suite de Selenium?
No por completo. Una suite de Selenium en la que la gente confía es un activo. Agrega cobertura de API en su propio nivel en lugar de mover nada.
¿Cómo probamos un flujo que abarca ambos?
Escríbelo como una sola prueba, de forma deliberada, mantén bajo su número y haz que la aserción sea lo bastante específica como para que un fallo te diga qué lado se rompió.
¿Playwright es mejor para esto?
Tiene una API de peticiones de primer nivel, así que la mecánica es más agradable. El argumento arquitectónico no cambia: las verificaciones de navegador y las de API responden preguntas distintas y es mejor mantenerlas separadas.
¿Y la autenticación entre ambos?
Comparte la fuente de credenciales, no la sesión. Cada capa debería obtener su propia sesión para que un fallo en una no se propague a la otra.
Usa el navegador para las preguntas de navegador.
Las pruebas de API con Selenium suelen consistir en coordinar dos tipos de verificación, en lugar de forzar a una sola herramienta a hacer ambas cosas. Reserva Selenium para los flujos que ve el usuario, cubre la API en su propio nivel y escribe a propósito las pruebas realmente transversales.