El nacimiento de la automatización de pruebas
Volvamos a la década de 1990, cuando nació el navegador web. La automatización de pruebas no se hizo realidad hasta la década del 2000, con el surgimiento de los proyectos de Selenium y WebDriver para abordar los desafíos de las pruebas en navegadores y dispositivos múltiples.
Estos dos proyectos se unieron en 2011 como Selenium WebDriver y se convirtieron en estándares del W3C en 2018. Por lo general, nos referimos a ella como WebDriver o WebDriver “clásico”.
La automatización de pruebas antes de WebDriver "Classic" era bastante complicada. La capacidad de automatizar las pruebas del navegador mejoró significativamente la calidad de la vida de los desarrolladores y verificadores.
El auge de JavaScript
A medida que el desarrollo web evolucionó para depender más de JavaScript, surgieron nuevas soluciones de automatización como WebdriverIO, Appium, Nightwatch, Protractor (obsoleto), Testcafe, Cypress, Puppeteer y Playwright.
Enfoques de automatización
En términos generales, estas herramientas se pueden organizar en dos grupos principales según la forma en que automatizan los navegadores:
- Alto nivel: Son herramientas que ejecutan JavaScript en el navegador. Por ejemplo, Cypress y TestCafe aprovechan las APIs web y Node.js para ejecutar pruebas directamente en el navegador. Dato curioso: la primera versión de Selenium también utilizó el mismo enfoque.
- Nivel bajo: Son herramientas que ejecutan comandos remotos fuera del navegador. Cuando las herramientas requieren aún más control, como abrir varias pestañas o simular el modo del dispositivo, es cuando necesitan ejecutar comandos remotos para controlar el navegador a través de protocolos. Los dos protocolos de automatización principales son WebDriver “Classic” y Chrome Herramientas para desarrolladores (CDP).
En la siguiente sección, revisaremos estos dos protocolos para comprender sus fortalezas y limitaciones.
WebDriver "Classic" versus el protocolo de las Herramientas para desarrolladores de Chrome (CDP)
WebDriver "Classic" es un estándar web compatible con todos los navegadores principales. Las secuencias de comandos de automatización emiten comandos a través de solicitudes HTTP a un servidor de controladores, que luego se comunica con los navegadores a través de protocolos internos específicos.
Si bien ofrece una excelente compatibilidad con varios navegadores y sus API están diseñadas para realizar pruebas, puede ser lenta y no admite algunos controles de bajo nivel.
Por ejemplo, imagina que tienes una secuencia de comandos de prueba que hace clic en un elemento await coffee.click();. Se traduce en una serie de solicitudes HTTP.
# WebDriver: Click on a coffee element
curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
-H 'Content-Type: application/json'
-d '{}'
Por otro lado, el Protocolo para las Herramientas para desarrolladores de Chrome (CDP) se diseñó inicialmente para las Herramientas para desarrolladores de Chrome y la depuración, pero Puppeteer lo adoptó con fines de automatización. CDP se comunica directamente con los navegadores basados en Chromium a través de las conexiones de WebSocket, lo que brinda un rendimiento más rápido y un control de bajo nivel.
Sin embargo, solo funciona con navegadores basados en Chromium y no es un estándar abierto. Además, las APIs de CDP son relativamente complejas. En algunos casos, trabajar con CDP no es ergonómico. Por ejemplo, trabajar con iframes fuera del proceso requiere mucho esfuerzo.
Por ejemplo, hacer clic en un elemento await coffee.click(); se traduce en una serie de comandos de CDP.
// CDP: Click on a coffee element
// Mouse pressed
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}
// Mouse released
{
command: 'Input.dispatchMouseEvent',
parameters: {
type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}
¿Qué son los controles de bajo nivel?
En los días en que se desarrolló WebDriver "Classic", no era necesario un control de bajo nivel. Sin embargo, los tiempos cambiaron, ahora la Web es mucho más capaz y las pruebas actuales exigen acciones más precisas.
Dado que CDP se diseñó para satisfacer todas las necesidades de depuración, admite controles más de bajo nivel en comparación con WebDriver "Classic". Es capaz de manejar funciones como las siguientes:
- Captura mensajes de la consola
- Interceptación de solicitudes de red
- Simula el modo de dispositivo
- Simula la ubicación geográfica
- Y mucho más.
Esto no era posible en WebDriver "Classic" debido a la diferente arquitectura. WebDriver "Classic" se basa en HTTP, por lo que resulta complicado suscribirse y escuchar los eventos del navegador. Por otro lado, CDP se basa en WebSocket y admite la mensajería bidireccional de forma predeterminada.
Próximos pasos: WebDriver BiDi
A continuación, se presenta un resumen de las fortalezas de WebDriver “Classic” y de CDP:
| WebDriver “Clásico” | Protocolo de las Herramientas para desarrolladores de Chrome (CDP) |
|---|---|
| Mejor compatibilidad con varios navegadores | Mensajería rápida y bidireccional |
| Estándar W3C | Proporciona control de bajo nivel |
| Creado para las pruebas |
WebDriver BiDi tiene como objetivo combinar los mejores aspectos de WebDriver "Classic" y CDP. Es un nuevo protocolo estándar de automatización de navegadores que actualmente está en desarrollo.
Obtén más información sobre el proyecto WebDriver BiDi: cómo funciona, la visión y el proceso de estandarización.