Selenium es un framework de automatización de navegadores. Controla Chrome, Firefox y otros navegadores de la misma manera que lo haría una persona: haciendo clic en botones, rellenando formularios, leyendo la página renderizada. Es la herramienta estándar para pruebas de UI de extremo a extremo, y es muy buena en ese trabajo.
La gente todavía pregunta si Selenium puede probar APIs. La respuesta honesta es que puedes hacer que emita llamadas HTTP, pero es la herramienta equivocada para ese trabajo. Esta guía explica exactamente por qué, muestra cómo se ve realmente la prueba de API a través de Selenium y te indica las herramientas que están diseñadas para la tarea. El objetivo es evitarte una configuración que te frustrará más tarde.
Por qué Selenium y las pruebas de API no coinciden
Una prueba de API envía una solicitud HTTP directamente a un servidor y verifica la respuesta: código de estado, encabezados, cuerpo, tiempo. No hay interfaz de usuario involucrada. La prueba debe ser rápida, aislada y barata de ejecutar miles de veces.
Selenium hace lo contrario por diseño. Inicia un navegador real, carga páginas y espera que JavaScript se renderice. Ese navegador es el objetivo principal cuando se prueba una UI, y es pura sobrecarga cuando se prueba una API. Una solicitud que un cliente dedicado envía en decenas de milisegundos se convierte en un asunto de varios segundos una vez que se involucra un proceso de navegador, una sesión de WebDriver y la renderización de la página.
También hay un desajuste más profundo. Toda la API de Selenium se centra en elementos de una página: buscar este botón, leer este texto, esperar este elemento. Una respuesta HTTP no es una página. No tiene DOM. Así que Selenium no te ofrece nada útil para inspeccionar un cuerpo JSON, afirmar sobre un encabezado o verificar un código de estado. Terminas trabajando alrededor de la herramienta en lugar de con ella.
El costo no es solo la velocidad. Las pruebas basadas en navegador son famosamente inestables (flaky). Fallan porque una página tardó un momento más en renderizarse, porque una sesión de WebDriver se cayó o porque una actualización del navegador cambió algún tiempo. Una prueba de API debe ser determinista: la misma solicitud produce la misma respuesta, y un fallo significa que algo realmente se rompió. Enrutar las verificaciones de API a través de Selenium importa toda esa inestabilidad del navegador a una capa que no tiene ninguna razón para ser inestable. Con el tiempo, un conjunto de pruebas inestable acostumbra al equipo a ignorar las compilaciones en rojo, lo que anula el propósito de las pruebas. La distinción entre validación y verificación es una buena lente aquí: Selenium verifica la experiencia renderizada, mientras que las pruebas de API validan el contrato subyacente.
Qué significa realmente "pruebas de API con Selenium"
Cuando los artículos afirman que Selenium puede probar APIs, generalmente se refieren a una de dos soluciones alternativas. Ninguna de ellas convierte a Selenium en una herramienta de prueba de API. Simplemente enrutan HTTP a través o junto a ella.
Opción uno: usar el ejecutor de JavaScript de Selenium. Selenium puede ejecutar JavaScript arbitrario en el navegador que controla. Los navegadores modernos tienen la API fetch, por lo que puedes pedirle al navegador que realice una solicitud y devuelva el resultado a tu código de prueba:
JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
"const callback = arguments[arguments.length - 1];" +
"fetch('https://jsonplaceholder.typicode.com/users/1')" +
" .then(r => callback(r.status))" +
" .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);
Esto funciona. También significa que has iniciado un navegador, un WebDriver y un puente JavaScript puramente para hacer una llamada HTTP que un cliente HTTP normal haría directamente. También heredas las restricciones del navegador como CORS, en las que una prueba de API de servidor a servidor nunca tiene que pensar.
Opción dos: ignorar Selenium y usar una librería HTTP real junto a ella. En un proyecto Java, esto significa emparejar Selenium con REST Assured para las partes de la API:
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;
given()
.when()
.get("https://jsonplaceholder.typicode.com/users/1")
.then()
.statusCode(200)
.body("email", equalTo("Sincere@april.biz"));
Nótese que la prueba de API real aquí es realizada enteramente por REST Assured. Selenium no contribuye en nada. Las dos librerías simplemente coexisten en el mismo proyecto. Esto está bien, pero no es "pruebas de API con Selenium". Es pruebas de API con una librería de pruebas de API adecuada, con Selenium presente para pruebas de UI no relacionadas.
Cuando mezclarlas es razonable
Hay un caso legítimo para el trabajo HTTP dentro de una suite de Selenium, y vale la pena ser claro al respecto. Las pruebas de UI de Selenium a menudo necesitan una configuración o desmontaje que es más rápido hacer a través de la API que a través del navegador.
Supongamos que tienes una prueba de UI que verifica la página del historial de pedidos. Para probarla, debe existir un pedido. Recorrer todo el flujo de pago en el navegador solo para crear ese pedido es lento y frágil. En su lugar, tu prueba realiza una llamada API directa para crear el pedido, luego usa Selenium solo para la parte que realmente necesita un navegador: cargar la página del historial y verificar que el pedido aparece.
Esa es una buena práctica. La llamada a la API es un medio para un fin, no lo que se está probando. La llamada a la API aún debe realizarse a través de un cliente HTTP real, no del ejecutor de JavaScript. Así que, incluso en este caso, Selenium no está realizando las pruebas de API. Está realizando las pruebas de UI, y un cliente HTTP adecuado maneja el lado de la API.
Este patrón de configuración a través de la API es lo suficientemente común como para que la mayoría de las suites de prueba maduras lo adopten deliberadamente. Mantiene la parte lenta y controlada por el navegador de la suite lo más pequeña posible, reservada para el puñado de viajes que realmente necesitan una página renderizada. Todo lo demás, incluida toda la preparación de datos y la mayor parte de la verificación, se realiza mediante llamadas HTTP rápidas. El resultado es una suite que se ejecuta en minutos en lugar de horas y falla por razones reales. Para una visión más amplia de cómo encajan las capas de UI y automatización, consulta pruebas funcionales versus pruebas automatizadas.
Usa una herramienta diseñada para pruebas de API
Si tu objetivo es probar APIs, usa algo diseñado para ello. La diferencia no es pequeña. Una herramienta real de prueba de API te ofrece creación de solicitudes, gestión de entornos, aserciones sobre el estado, encabezados y cuerpo, encadenamiento de solicitudes, ejecuciones impulsadas por datos e integración CI, sin necesidad de iniciar un navegador.
Tus opciones se dividen en varios grupos:
| Enfoque | Mejor para | Adecuación para pruebas API |
|---|---|---|
| Selenium | Pruebas UI / de extremo a extremo del navegador | Mala. No diseñado para HTTP. |
| REST Assured / requests / supertest | Pruebas API dentro de un proyecto de código | Buena. Librerías HTTP reales. |
| Postman, Insomnia, Talend API Tester | Pruebas API manuales y con scripts | Buena. Clientes diseñados para ello. |
| Apidog | Ciclo de vida completo de la API: diseño, depuración, mock, prueba, documentación | Fuerte. Un solo espacio de trabajo para todo. |
Si prefieres código, una librería HTTP como REST Assured en Java, `requests` en Python o `supertest` en Node es la elección correcta. Estas librerías realizan una solicitud y te devuelven la respuesta directamente, con ayudantes de aserción incorporados para códigos de estado y cuerpos JSON. No hay navegador, ni WebDriver, ni renderización, por lo que una suite completa se ejecuta rápidamente y falla solo cuando la API misma cambia.
Si deseas un espacio de trabajo visual, Apidog es una plataforma API todo en uno que cubre el diseño de la API, la depuración de solicitudes, la simulación de endpoints, la construcción de escenarios de prueba automatizados y la generación de documentación, todo en un solo proyecto. Construyes aserciones visualmente o con scripts, encadenas solicitudes en flujos de varios pasos, ejecutas iteraciones impulsadas por datos y ejecutas todo en CI. También importa archivos OpenAPI y Postman, por lo que una API existente se incorpora rápidamente. Nada de esto implica un navegador, porque nada de esto debería. Puedes descargar Apidog para probarlo con una API real.
Para equipos que desean un framework centrado en el código, las guías sobre Robot Framework para la automatización de API y la construcción de un framework de pruebas de automatización de API cubren enfoques que, a diferencia de Selenium, son realmente adecuados para las pruebas HTTP.
La conclusión honesta
Selenium es un software excelente para lo que fue construido: automatizar navegadores. Las pruebas de API no son eso. Técnicamente, puedes enviar HTTP a través del ejecutor de JavaScript de Selenium, y puedes mantener una librería HTTP en el mismo proyecto que Selenium, pero en ninguno de los casos Selenium agrega valor a la propia prueba de API.
Elegir la herramienta equivocada no es una decisión neutral. Hace que tus pruebas sean más lentas, más difíciles de mantener y propensas a fallos que no tienen nada que ver con tu API. Opta por una herramienta diseñada para la tarea. Tu suite de pruebas será más rápida, más fiable y mucho más fácil de razonar. El resumen de las mejores plataformas de pruebas automatizadas es un buen lugar para comparar opciones específicas.
Preguntas frecuentes
¿Puede Selenium probar APIs REST?
Puede emitir solicitudes HTTP a través del ejecutor de JavaScript del navegador, así que, en un sentido técnico estricto, sí. Pero Selenium no tiene funciones para inspeccionar respuestas, afirmar sobre JSON o verificar encabezados, y conlleva toda la sobrecarga de un navegador. No es una herramienta de prueba de API REST, y usarlo como tal crea pruebas lentas y frágiles.
¿Por qué algunos tutoriales muestran Selenium con REST Assured?
Porque las pruebas de API en esos tutoriales son realizadas enteramente por REST Assured, que es una librería real de pruebas HTTP. Selenium simplemente está presente en el mismo proyecto para pruebas de UI no relacionadas. El emparejamiento está bien, pero no significa que Selenium esté probando la API. Lo hace REST Assured.
¿Está bien hacer llamadas a la API en una prueba de Selenium?
Sí, para la configuración y el desmontaje. Crear datos de prueba a través de la API es más rápido y fiable que hacer clic en la UI para producirlos. La llamada a la API apoya la prueba de UI en lugar de ser lo que se está probando, y aún debe usar un cliente HTTP adecuado, no el ejecutor de JavaScript de Selenium.
¿Qué debería usar en lugar de Selenium para pruebas de API?
Para pruebas centradas en el código, una librería HTTP como REST Assured, `requests` de Python o `supertest` para Node. Para un espacio de trabajo visual, una plataforma API dedicada como Apidog, o clientes como Postman, Insomnia y Talend API Tester. Todos estos están diseñados para HTTP y evitan la sobrecarga del navegador que impone Selenium.
¿El uso de Selenium para pruebas de API ralentiza mi pipeline de CI?
Significativamente. Cada llamada a la API basada en Selenium inicia un proceso de navegador y una sesión de WebDriver, convirtiendo una solicitud HTTP de menos de un segundo en una operación de varios segundos. En una suite, esto se suma a ejecuciones de pipeline largas e inestables. Una herramienta dedicada a las pruebas de API realiza las mismas verificaciones mucho más rápido porque nunca inicia un navegador.