Automatización de Pruebas Funcionales: Comparación Técnica de los Frameworks Cypress, Playwright e Selenium
Resumen. En el contexto del desarrollo de software utilizando métodos ágiles, tener retroalimentación rápida y continua es crucial para el éxito de los proyectos. Una de las formas de garantizar una detección rápida de errores es mediante la ejecución de pruebas automatizadas. Dado el alto valor de las pruebas automatizadas, es necesario evaluar los distintos frameworks actualmente disponibles en el mercado para determinar cuál se adapta mejor a las necesidades del proyecto. Este trabajo se propone un análisis comparativo entre tres frameworks de pruebas: Selenium, una de las herramientas de automatización más tradicionales; Cypress, herramienta que ha ganado mucha popularidad en los últimos años; y Playwright, una herramienta más nueva que ha recibido mucha atención. Para realizar este análisis, se desarrollaron conjuntos de pruebas automatizadas para una aplicación web, con el objetivo de comparar los scripts generados en función de criterios seleccionados. De esta manera, se presentarán los pros y contras de trabajar con cada uno de estos frameworks.
Las pruebas de software, entre otros objetivos, buscan detectar fallas y defectos existentes con el fin de reducir los niveles de riesgo de calidad del software [ISTQB-CTFL]. La Regla 10 de Myers establece que el costo de corregir defectos tiende a aumentar cuanto más tarde se detecta el defecto. Los defectos encontrados durante la producción tienden a costar mucho más que los defectos encontrados en los modelos de datos y otros documentos de diseño de software. De esta manera, al tratar las pruebas como un proceso organizado que a menudo es paralelo e integrado con el proceso de desarollo, se reducirán los costos de manteniemiento. [Bastos 2007]
Hoy en día, constantemente se lanzan muchas opciones de software, por lo que el costo de cambiar de software ha disminuido como solía ser. Por esta razón, es cada vez más común la adopción de métodos ágiles de desarrollo, para satisfacer las necesidades de los clientes con incrementos constantes y correcciones rápidas. Como resultado, el plazo para lanzar una aplicación es cada vez más dinámico y, en consecuencia, el tiempo disponible para la ejecución de la prueba es cada vez más corto.
Debido al menor tiempo que lleva desarrollar y lanzar una aplicación, se hacen necesarias pruebas automáticas para encontrar defectos y garantizar la calidad durante los ciclos de desarrollo. La automatización de pruebas es el uso de software para controlar la ejecución de pruebas de software mediante la aplicación de estrategias y herramientas, comparando los resultados esperados con los resultados reales. Sus objetivos son reducir la implicación humana en las actividades manuales, las exigencias de tiempo y los costos finales. [Oliveira 2018]
Actualmente, existen muchas opciones de frameworks para la automatización de pruebas, muchas de ellas de código abierto, pero incluso la selección de un framework de código abierto para su adopción en la empresa no está libre de costos, después de todo, se debe tener en cuenta la curva de desarollo con un framework, que afectará el tiempo de formación necesario para que un empleado aprenda a utilizarlo. Además, es necesario comprobar si el framework satisface todas las necesidades de uso, de lo contrario, será necesario modificarlo mediante personalización o instalación de complementos de terceros. Estos factores hacen que la elección de un framework sea una tarea compleja que requiere un buen análisis.
Uno de los frameworks más tradicionales y conocidos es Selenium, un proyecto integral para una variedad de herramientas y bibliotecas que permiten y respaldan la automatización del navegador web [Selenium 2023a]. Aunque su primera versión fue creada en el año 2004, el framework se encuentra actualmente en la versión 4.0 y cuenta con un gran apoyo por parte de la comunidad, como se puede observar en la Tabla 1 [Selenium 2024a].
| Framework | Linguajes soportadas | Copias en GitHub | Estrellas en GitHub |
|---|---|---|---|
| Selenium | Java, Javascript, Python, Ruby, C# | 7.9K | 29K |
Tabla 1. Datos sobre el framework Selenium
Cypress es una herramienta de prueba front-end reciente creada para aplicaciones web modernas. Se puede destacar que aborda los principales puntos débiles que enfrentan los desarrolladores e ingenieros de control de calidad al probar aplicaciones modernas [Cypress 2024a]. Aunque fue creado en 2017, Cypress actualmente cuenta con una gran cantidad de usuarios activos, como se muestra en la Tabla 2. [Cypress 2024b]
| Framework | Linguajes soportadas | Copias en GitHub | Estrellas en GitHub |
|---|---|---|---|
| Cypress | Javascript | 3.1K | 45.9K |
Tabla 2. Datos sobre el framework Cypress
Playwright fue creado específicamente para satisfacer las necesidades de pruebas de un extremo a otro. Capaz de soportar todos los motores de renderización modernos, incluidos Chromium, WebKit y Firefox [Playwright 2024a], fue diseñado en 2020 por Microsoft y ha estado atrayendo mucha atención por parte de la comunidad, como se puede ver en la Tabla 3 [Playwright 2024b].
| Framework | Linguajes soportadas | Copias en GitHub | Estrellas en GitHub |
|---|---|---|---|
| Playwright | Java, Javascript, Python, C# | 3.2K | 60.1K |
Tabla 3. Datos sobre el framework Playwright
Aunque es más reciente, Playwright ya superó a Selenium en el número de descargas y a pesar de haber cerrado la brecha con Cypress en último año, todavía está lejos del número de descargas de Cypress, situación que se muestra en la Figura 1.
Figura 1. Número de descargas de cada framework en los últimos 5 años. [NPM Trends 2024]
Por lo anterior, este trabajo tiene como objetivo identificar las principales funcionalidades y limitaciones de los frameworks seleccionados, realizar configuraciones del entorno, desarrollar la arquitectura del proyecto de automatización, con el fin de seguir buenas prácticas de ingeniería de software, desarrollar los mismos scripts de prueba en cada framework, ejecutar y validar para comparar los resultados obtenidos posteriormente.
Selenium es una colección de diferentes herramientas para automatización que permite probar aplicaciones en el navegador. Lanzado en 2004, fue creado por Thoughtworks, y sus principales componentes son Selenium Grid, Selenium IDE, Selenium RC y Selenium Webdriver. Es compatible con los principales navegadores del mercado, como Chrome, Firefox, Safari, Internet Explorer, Edge, Opera, entre otros. Sus scripts son compatibles con lenguajes como Javascript, Java, Ruby, C# y Python. [Akhtar 2023]
Dado que fue desarrollado inicialmente en una época en la que los navegadores eran mucho más simples en comparación con los actuales, una de las críticas comunes es que Selenium tiende a ser más lento en comparación con frameworks más nuevos [Raggo 2023]. Además, suele ser más inestable debido a la presencia de pruebas flake, causada pr la necesidad de incluir esperas implícitas o explícitas en el script [Pathak 2023].
Cypress, a diferencia de la gran mayoría de las herramientas de automatización, no fue desarrollado sobre Selenium y, por esta razón, no está limitado por sus capacidades. Está enfocado en pruebas de extremo a extremo, y sus scripts de prueba se escriben únicamente en Javascript. Así, Cypress es una suite de pruebas completa con su propio ejecutor y generación de reportes. Es compatible con navegadores como Firefox y todos los basados en Chromium, como Chrome, Edge y Electron. La herramienta incluye la capacidad de grabar videos y capturar pantallas durante la ejecución de pruebas [Döring y Brueckner 2022].
Cypress tiene su mejor rendimiento en pruebas locales, pero puede no ser la opción más rápida para ejecutar pruebas en sitios en vivo. Su tiempo de inicio elevado puede interferir en escenarios de monitoreo de alta frecuencia, aunque probablemente no tenga un impacto real en el contexto de compilacionaes clásicas de pruebas E2E [Raggo 2024].
Playwright, al igual que Cypress, no fue construido sobre Selenium y es una solución completamente independiente. Ofrece soporte para todos los principales navegadores y diferentes lenguajes de programación, como Java, Javascript y Python. Además, proporciona opciones para capturas de pantalla, videos y rastreo de ejecución con soporte inmediato. Incluye su propio ejecutor de pruebas, pero puede integrarse con otro de elección del usuário. También permite ejecutar pruebas en varias pestañas, orígenes y usuarios dentro de una misma prueba [Döring y Brueckner 2022].
Playwright admite pruebas de API, pero no permite desactivar redirecciones, y emula dispositivos móviles utilizando navegadores de desktop en lugar de dispositivos reales [Akhtar 2023].
Los estudios Puppeteer vs Selenium vs Playwright, a speed comparison [Raggo 2023], Cypress vs Selenium vs Playwright vs Puppeteer speed comparison [Raggo 2024], Why we favor Playwright over Selenium or Cypress [Döring and Brueckner 2022], Cypress vs Selenium vs Playwright vs Puppeteer: Core Differences [Akhtar 2023], Playwright vs Selenium vs Cypress: A Detailed Comparison [Pathak 2023], and Automação de testes funcionais para aplicações web: comparativo dos frameworks Cypress e Playwright [França 2023] realizan estudios similares a los presentados aquí, en cuanto a la comparación entre Selenium, Cypress y Playwright.
Las métricas utilizadas en estos estudios son similares a las empleadas en este trabajo. Por ello, se menciona la comparación del tiempo de codificación y ejecución de los scripts; el análisis del soporte para diferentes lenguajes de programación y navegadores; la facilidad para realizar la configuración inicial del proyecto; la necesidad de instalar bibliotecas externas para capturar pantallas y videos; la arquitectura en la que fueron construidos; la capacidad de integración con herramientas de CI/CD; y, finalmente, el soporte para pruebas de API y dispositivos móviles.
El experimento realizado en este trabajo se llevará a cabo automatizando la misma suite de pruebas del sitio Sauce Demo en los diferentes frameworks, utilizando en lenguaje Javascript y el patrón Page Objects, para garantizar que el uso de un lenguaje diferente no influya en el tiempo de ejecución de las pruebas. Sin embargo, en los estudios que inspiraron este trabajo también se evalúa Puppeteer 1, el cual ha sido excluido aquí debido a su gran similitud con Playwright.
El sitio Sauce Demo (http://www.saucedemo.com), creado con el objetivo de practicar la automatización de pruebas, se utilizó como ejemplo de aplicación web gracias a la posibilidad de crear escenarios de pruebas E2E.
En el presente estudio, se realizó un experimento en el que se analizaron los frameworks Selenium, Cypress y Playwright, implementando una suite de pruebas automatizadas con cada uno de ellos. El objetivo principal fue identificar las características distintivas de cada framework durante el proceso de desarrollo de scripts de prueba, permitiendo determinar las ventajas y desvantajas de cada herramienta.
Para una comparación efectiva, fue necesario definir ciertas métricas que permitieran analizar y evaluar las diferencias entre los frameworks, identificando sus puntos fuertes y débiles. Las métricas utilizadas en el análisis fueron:
- Facilidad para configurar el proyecto inicial y necesidad de instalación de bibliotecas externas.
- Arquitectura del framework.
- Tiempo empleado en la codificación del proyecto de automatización.
- Tiempo de ejecución de los scripts de prueba.
El sitio Sauce Demo (https://www.saucedemo.com/), utilizado como base para la comparación de la automatización, es una aplicación web sencilla que permite realizar un flujo E2E simulando la compra de productos en un sitio de comercio electrónico. Para ello, se creó una suite completa con 23 casos de prueba que abarcan todas las funcionalidades del sitio, garantizando que las diferencias de desempeño sean más perceptibles al trabajar con un conjunto extenso de pruebas en lugar de un solo caso de prueba. Los scripts de prueba utilizados en el análisis se presentan en la Tabla 4.
| Feature | Caso de prueba | Objetivo de la prueba |
|---|---|---|
| Login | CT01 - Iniciar sesión con usuario estándar | Verificar que el inicio de sesión se realiza correctamente con un usuario estándar. |
| Login | CT02 - Iniciar sesión con usuario bloqueado | Verificar que se muestra un mensaje de error impidiendo el inicio de sesión con un usuario bloqueado. |
| Login | CT03 - Iniciar sesión con usuario con problemas | Verificar que se muestra una versión del sitio con imágenes de productos incorrectas al iniciar sesión con un usuario con problemas. |
| Login | CT04 - Iniciar sesión con errores de rendimiento | Verificar que el inicio de sesión se realiza con lentitud al usar un usuario con errores de rendimiento. |
| Login | CT05 - Iniciar sesión con error de diseño | Verificar que se muestra una versión del sitio donde algunos productos tienen imágenes fuera del tamaño estándar al iniciar sesión con un usuario con errores de diseño. |
| Products | CT06 - Añadir producto al carrito y validar que se guardó correctamente | Validar que el producto puede añadirse al carrito desde la página de lista de productos. |
| Products | CT07 - Eliminar producto del carrito desde la página de productos | Validar que el producto puede eliminarse del carrito desde la página de lista de productos. |
| Products | CT08 - Añadir producto al carrito desde la página del producto y verificar que se guardó correctamente | Validar que el producto puede añadirse al carrito desde la página de detalle del producto. |
| Products | CT09 - Eliminar producto del carrito desde la página del producto y volver a la lista de productos | Validar que el producto puede eliminarse del carrito desde la página de detalle del producto y regresar a la página de lista de productos. |
| Products | CT10 - Validar añadir y eliminar todos los productos al carrito | Validar que todos los botones de añadir y eliminar productos de la página de lista de productos funcionan correctamente. |
| Products | CT11 - Validar ordenamiento por defecto en orden alfabético ascendente | Validar que el orden alfabético ascendente por defecto se presenta al acceder a la página de lista de productos. |
| Products | CT12 - Ordenar productos en orden alfabético descendente | Validar que al cambiar el orden a alfabético descendente en la página de lista de productos, los productos se presentan correctamente. |
| Products | CT13 - Ordenar productos por precio de menor a mayor | Validar que al ordenar los productos por precio de menor a mayor en la página de lista, estos se presentan correctamente. |
| Products | CT14 - Ordenar productos por precio de mayor a menor | Validar que al ordenar los productos por precio de mayor a menor en la página de lista, estos se presentan correctamente. |
| Your Cart | CT15 - Validar botón "continuar comprando" | Validar que el botón "Continuar comprando" redirige nuevamente a la página de lista de productos. |
| Your Cart | CT16 - Validar botón "eliminar producto" | Validar que el botón "Eliminar producto" elimina correctamente el producto del carrito. |
| Your Cart | CCT17 - Validar botón "checkout" | Validar que el botón "Checkout" redirige a la página de información de compra. |
| Checkout Your Information | CT18 - Validar que el botón "cancelar" retorna al carrito sin guardar datos | Validar que al hacer clic en el botón "Cancelar", los datos ingresados no se guardan y se retorna al carrito. |
| Checkout Your Information | CT19 - Validar rellenar campos de texto y continuar | Validar que al hacer clic en el botón "Continuar", los datos ingresados se guardan. |
| Checkout Your Information | CT20 - Validar obligatoriedad de los campos de texto | Validar que al hacer clic en "Continuar", se muestran mensajes de validación para los campos obligatorios. |
| Checkout Overview | CT21 - Validar que el botón "cancelar" retorna a la página de productos | Validar que al hacer clic en "Cancelar", el usuario es redirigido a la lista de productos. |
| Checkout Overview | CT22 - Validar que el botón "continuar" finaliza el pedido | Validar que al hacer clic en "Continuar", se finaliza el pedido y se redirige a la página de confirmación de éxito. |
| Checkout Complete | CT23 - Validar que el botón "volver a inicio" redirige a la página de productos | Validar que al hacer clic en "Back Home" en la página de confirmación de compra, el usuario es redirigido a la lista de productos. |
Tabla 4. Casos de Prueba Automatizados
Para garantizar que no existieran discrepancias debidas a diferencias en los entornos de ejecución, todas las suites de prueba se ejecutaron localmente en el mismo equipo. A continuación, se detallan las especificaciones de la máquina utilizada:
- Ordenador: Samsung Expert X50 NP350XBE-XH3BR
- Procesador: QuadCore Intel Core i7-8565U, 4050 MHz (42x96)
- Memoria: 20 GB 2667 MHz DDR4
- Tarjeta gráfica: NVIDIA GeForce MX110 2048MB
- Sistema operativo: Microsoft Windows 11 Home Single Language
- Navegador: Google Chrome
El estudio comenzó con la instalación y configuración del framework Cypress, que resultó ser muy sencilla. El único requisito previo solicitado por Cypress es la presencia de Node.js instalado en la máquina de trabajo donde se instalará y configurará el proyecto de automatización.
De forma secuencial, se utilizaron los comandos "npm init" para iniciar el proyecto y "npm install cypress" para instalar las dependencias de Cypress, lo que dejó el archivo package.json, como se muestra en la Figura 2.
Figura 2. Archivo package.json del proyecto poc_cypress.
No fue necesario instalar dependencias adicionales para el proyecto Cypress, ya que el framework incluye sus propias bibliotecas de pruebas, generación de reportes, herramientas de aserción, y no requiere configuraciones para capturas de fotos o videos durante la ejecución de pruebas, dado que es una funcionalidad nativa del framework.
La configuración inicial del proyecto también es facilitada al ejecutar el comando "npx cypress open" que abre el ejecutor de Cypress y crea la estructura básica de carpetas en su primera ejecución. Este proyecto se encuentra disponible públicamente en GitHub: https://github.com/AndradeTC86/poc_cypress
Posteriormente, se procedió con la instalación y configuración de Playwright, que también resultó ser muy sencilla y tenía como único requisito previo la instalación de Node.js en la estación de trabajo. Tras la creación del directorio, se ejecutó el comando "npm init playwright@latest" que realizó la instalación del framework con una serie de preguntas relacionadas con la configuración del proyecto. Inicialmente, se preguntó qué lenguaje de programación se utilizaría (JavaScript o TypeScript), el nombre de la carpeta para almacenar los scripts de pruebas, si se deseaba configurar el flujo de Github Actions y, por ultimo, si se deseaba instalar los navegadores compatibles con Playwright.
Tras seleccionar las opciones deseadas, se instaló una dependencia adicional, @types/node, para resolver las dificultades de JavaScript con las definiciones de tipos das bibliotecas do Node, como, por exemplo, para utilizar require para importar páginas y comandos personalizados. Al finalizar la instalación, el archivo package.json quedó como se muestra en la Figura 3.
Figura 3. Archivo package.json del proyecto poc_playwright.
No fue necesario instalar bibliotecas adicionales, ya que Playwright incluye soporte nativo para pruebas, reportes, capturas de pantalla y herramientas de aserción. Sin embargo, también ofrece compatibilidad con diversos frameworks de pruebas adicionales.
En cuanto a la organización del proyecto, únicamente se creó la carpeta previamente establecida para los scripts de pruebas, siendo necesario estructuras manualmente las demás carpetas, lo que podría complicar el trabajo a usuarios con menos experiencia en automatización de pruebas..
De forma nativa, Playwright ejecuta las pruebas en modo headless, en los navegadores instalados disponibles en la máquina local, y de manera paralela, con una cantidad de sesiones ajustada a la capacidad de memoria y procesamiento del equipo. En mi máquina local, se utilizaron hasta cuatro sesiones simultáneas. Por defecto, si ocurre algún error en una prueba, Playwright genera automáticamente un reporte de fallos. Si todas las pruebas se completan con éxito, el reporte no se abre automáticamente, pero puede visualizarse ejecutando el comando "npx playwright show-report". Este proyecto está disponible públicamente en GitHub: https://github.com/AndradeTC86/poc_playwright
El último framework instalado fue Selenium, que requirió más configuraciones iniciales. No tiene requisitos previos específicos y puede configurarse en proyectos que utilicen cualquiera de los lenguajes de programación compatibles. Dado que el proyecto de automatización se desarrolló con el mismo lenguaje utilizado en los demás proyectos, se empleó Node.js como base para la instalación.
Se utilizó el comando "npm install selenium" para instalar el framework. Debido a que no incluye soporte nativo, fue necesario instalar dependencias adicionales, como Axios para realizar solicitudes a APIs y verificar el tiempo de respuesta del inicio de sesión, Chai para las bibliotecas de aserción y Mocha como framework para la ejecución de pruebas. Esto obligó a cambiar las extensiones de los archivos de .js para .mjs, lo que resultó en un archivo package.json como se muestra en la Figura 4.
Figura 4. Archivo package.json del proyecto poc_selenium.
Toda la organización de las carpetas del proyecto tuvo que ser creada manualmente, sin la ayuda del framework para esta tarea.
La nueva versión de Selenium introdujo una mejora significativa al permitir la descarga automática de los driver según el navegador que se utilice, lo que simplificó mucho el proceso en comparación con versiones anteriores, donde era necesario descargar y almacenar manualmente la versión deseada del driver en un directorio local para ejecutar las pruebas. Este proyecto está disponible públicamente en GitHub: https://github.com/AndradeTC86/poc_selenium
Entre los frameworks evaludos, Cypress demonstró ser el más sencillo de instalar, al no requerir dependencias externas y configurar automáticamente las carpetas en su primera ejecución.
Playwright también fue fácil de instalar, sin dependencias adicionales y con la configuración básica creada tras ejecutar un único comando.
En este aspecto, Selenium resultó ser el más complejo de instalar, al requirir bibliotecas externas y configuraciones iniciales completamente manuales.
Cypress es un framework de pruebas utilizado para la automatización de aplicaciones web. Posee una arquitectura única diseñada para ejecutar pruebas de manera rápida y confiable. En las pruebas de la interfaz de usuario, todos los comandos se ejecutan directamente en el navegador sin depender de ningún controlador. Como la ejecución de las pruebas se realiza directamente en el navegador, estas son más rápidas y no se ven afectadas por la velocidad de la red. La Figura 5 presenta una visualización de la arquitectura de Cypress.
Figura 5. Arquitcetura de Cypress. [Tutorials Point 2020]
Hay un servidor Node detrás de Cypress, y el proceso de Node se comunica, sincroniza y ejecuta tareas constantemente en apoyo mutuo. El servidor Node y el navegador se comunican a través de WebSocket, que se inicia tan pronto como se crea el proxy. Debido a esta forma de ejecutar pruebas dentro del navegador, es más fácil trabajar directamente con el DOM2, la capa de red y el almacenamiento local. Gracias a esta facilidad de acceso, Cypress ofrece ventajas significativas en la ejecución de pruebas en comparación con otros frameworks. [Pathak 2023]
Playwright trabaja directamente con WebSocket, lo que significa que tan pronto como se inicia la prueba, el código se convierte al formato JSON y se envía al servidor utilizando el protocolo WebSocket. Una vez establecida la conexión, los comandos se transmiten entre la prueba y el servidor de Playwright. La arquitectura de Playwright se presenta en la Figura 6.
Figura 6. Arquitectura de Playwright [Learn Microsoft 2023]
Las conexiones entre el cliente y el servidor permanecen activas hasta que una o ambas las partes las interrumpen. Una vez cerrada la conexión, se termina en ambos extremos. Una de las razones por las que Playwright es rápido es que la conexión permanece activa mientras ninguna de las partes la finalice. [Pathak 2023]
Selenium es un framework de pruebas de código abierto utilizado para la automatización de pruebas web. El protocolo JSON Wire fue eliminado en Selenium 4 en favor de WebDriver W3C, que ahora es el estándar oficial para controlar navegadores web. SIn embargo, el equipo de Selenium sigue proporcionado soporte al protocolo obsoleto.
El nuevo protocolo, denominado WebDriver W3C, ha sido aceptado por el “World Wide Web Consortium” (W3C). En la arquitectura de Selenium 4, se puede observar la comunicación directa entre cliente y el servidor sin necesidad del protocolo JSON Wire. Este mismo protocolo es utilizado tanto por Selenium WebDriver como por los navegadores web, lo que hace que la ejecución de las pruebas sea más rápida y la inestabilidad extremamente baja. Un ejemplo de la arquitectura de Selenium se muestra en la Figura 7.
Figura 7. Arquitectura de Selenium [Pathak 2023]
Existen muchos beneficios en adoptar el protocolo WebDriver W3C, que es más avanzado en comparación con JSON Wire. Cabe destacar que la API de acciones fue rediseñada para alinearse con la especificación de WebDriver y ahora permite realizar acciones multitáctiles, ampliar o reducir el zoom, presionar dos teclas simultáneamente, entre otras funcionalidades [Pathak 2023].
La arquitectura de Playwright ha demonstrado ser la más moderna entre las evaludas, siendo una excelente opción, ya que mantiene la conexión activa durante la ejecución de las pruebas, lo que proporciona una mayor velocidad en su ejecución con una complejidad algo mayor.
La arquitectura de Cypress, al ejecutar directamente en el navegador, también ofrece velocidad y presenta una forma más simplificada de comunicarse con la página que se está probando.
Por otro lado, la arquitectura de Selenium, aunque es bastante robusta y amplamente utilizada, puede ser menos rápida y sencilla en comparación con las otras herramientas.
El objetivo de esta sección es evaluar la facilidad para codificar las pruebas en cada uno de los frameworks, comparando la cantidad de código necesario para automatizar las mismas pruebas y también la dificultad para aprender la sintaxis de cada uno.
Cypress solo admite Javascript, lo que puede requerir que el tester aprenda un nuevo lenguaje de programación. Sin embargo, su sintaxis simple hace que la curva de aprendizaje sea muy baja.
Cypress tiene una interfaz amigable para el usuario a través del Test Runner, que ayuda en la configuración de pruebas E2E o de componentes para pruebas unitarias. Al seleccionar por primera vez el tipo de prueba deseado, el Test Runner crea las estructuras de carpetas con ejemplos de pruebas simples que sirven como modelos para la creación de nuevas pruebas. La interfaz del Test Runner se presenta en la Figura 8.
Figura 8. Pantalla inicial del Test Runner de Cypress
En la ejecución de pruebas E2E, Cypress carga automáticamente los navegadores instalados en la máquina. Actualmente, el framework admite Chrome, Edge, Firefox, Safari y Electron, este último un navegador integrado en Cypress. Después de seleccionar el navegador deseado, se presentan los archivos de prueba existentes para su ejecución en modo depuración.
El modo depuración ayuda considerablemente al tester a comprender qué está ocurriendo en cada momento de la prueba, ya que muestra capturas de pantalla de cada paso, un informe de las llamadas API ejecutadas y un registro de los valores ingresados. Al hacer clic en el icono en forma de mira y en el elemento deseado, se muestra el mejor selector para ese elemento, siguiendo buenas prácticas de programación, lo que ayuda a los usuarios con menos experiencia a encontrar los selectores correctamente. En la Figura 9, se muestra un ejemplo de una prueba ejecutada con éxito en modo depuración y un selector encontrado.
Figura 9. Prueba ejecutada por el Test Runner.
Las configuraciones básicas del proyecto, como URL base, configuraciones de seguridad y otra información necesaria para ejecutar las pruebas, se almacenan en el archivo cypress.config.js, ubicado en la raíz del proyecto. Cabe destacar que Cypress presentó un problema de compatibilidad con el sitio utilizado en el estudio, bloqueándose al intentar realizar el login. Para resolver este problema, fue necesario configurar Cypress para que ignorara las configuraciones de seguridad del navegador, lo que sería un problema en una prueba real.
Cypress, por defecto, siempre espera que los elementos sean visibles antes de intentar interactuar con ellos, lo que reduce la cantidad de pruebas fallidas debido a la falta de respuesta dentro del tiempo de espera. Si se necesita esperar más, se puede usar el comando cy.wait, pero en mi experiencia con la automatización, no fue necesario.
Cypress cierra automáticamente el navegador al final de cada prueba, por lo que no es necesario crear un método para cerrarlo después de cada prueba. El framework también admite pruebas de comunicación con API de forma nativa mediante los comandos cy.request, que realiza una solicitud a través de la API, y cy.intercept, que permite capturar una solicitud y modificarla, ideal para simular errores que no serían fáciles de recrear en la ejecución de la prueba.
Gracias a la facilidad para mapear los objetos de la página, así como para codificar las pruebas sin la necesidad de importar muchas bibliotecas externas, el proyecto tuvo la menor cantidad de líneas de código en comparación con otros frameworks, como se observa en la Figura 10.
Figura 10. Cantidad de líneas de código del proyecto poc_cypress [Code Tabs 2024a]
Playwright admite los lenguajes de programación Java, C#, Python, Javascript y Typescript, lo que facilita la adopción de la herramienta sin necesidad de aprender un lenguaje específico para la codificación.
Al inicializar un proyecto en Playwright, se crean las carpetas de prueba con ejemplos para ayudar en la creación de nuevas pruebas. Las configuraciones básicas, como la URL base, los directorios de prueba, el formato de informe y los navegadores que se ejecutarán en paralelo, se almacenan en el archivo playwright.config.js, también creado al inicio.
La captura de selectores se realiza manualmente, lo que requiere que el usuario tenga conocimientos básicos para encontrar los elementos de una página que será probada. No obstante, la ejecución de la prueba en modo depuración ayuda mucho a comprender lo que se está haciendo, ya que muestra, en cada paso ejecutado, la ubicación del elemento buscado. La funcionalidad del modo depuración se puede observar en la Figura 11.
Figura 11. Modo depuración de Playwright
Las pruebas en Playwright se ejecutan de forma asincrónica. Por esta razón, siempre es necesario agregar async en los nombres de las funciones y await en las llamadas. Gracias a esto, todas las esperas se realizan automáticamente, sin necesidad de configurar tiempos de espera. Las pruebas en Playwright pueden ejecutarse en Chromium, Firefox o Webkit, siendo fácil trabajar con todos los navegadores en cuanto al rendimiento del tiempo de espera.
Playwright cierra automáticamente el navegador al finalizar cada prueba, generando informes automáticos de cada ejecución. En caso de fallo, el informe se abre en el navegador para mostrar el paso donde ocurrió el error.
Aunque cuenta con soporte nativo para bibliotecas de asertividad y comunicación con API, es necesario importar estas clases desde Playwright, lo que añade algunas líneas de código adicionales, aunque no afecta significativamente el tamaño del proyecto. Otro factor que aumentó el número de líneas de código, como se observa en la Figura 12, fue la necesidad de inicializar variables para que cada nueba página abierta heredara el driver de la página anterior.
Figura 12. Cantidad de líneas de código del proyecto poc_playwright [Code Tabs 2024b]
El Selenium, al ser más antiguo, ofrece soporte para más lenguajes que los otros frameworks analizados, pudiendo ser utilizado con Java, C#, Python, PHP, Perl, Ruby, Javascript y Typescript. Esto reduce la necesidad de aprender un nuevo lenguaje de programación para realizar la automatización de pruebas.
Como el proyecto se desarolló en VS Code, toda la estructura tuvo que ser creada desde cero, ya que Selenium no proporciona herramientas para asistir en la creación del proyecto ni genera pruebas de ejemplo, como sucede con los otros frameworks. Esto exige conocimientos básicos sobre la automatización de pruebas, siendo un recurso más adecuado para usuarios con mayor experiencia.
No existe un archivo estándar de configuración del proyecto, y Selenium funciona mejor con el modelo de Page Objects. Por ello, los métodos básicos como rellenar campos, hacer clic en botones, buscar valores de elementos, entre otras funciones comunes, se crean en la página base con la intención de ser reutilizados en otras páginas.
También es necesario crear una prueba base con los métodos para iniciar y cerrar el driver antes y después de cada ejecución, ya que el navegador no se cierra automáticamente al final de la prueba a menos que se cree un comando específicamente para ello.
La captura de los elementos también se realiza manualmente, pero Selenium no cuenta con una herramienta nativa para identificar selectores, lo que obliga a buscar alternativas en el navegador de preferencia. Tampoco cuenta con una herramienta de depuración nativa, lo que obliga a generar logs para identificar problemas que puedan surgir durante la prueba o a usar el sistema de depuración de la propia IDE (VS Code) utilizada para la codificación.
Selenium no tiene esperas predeterminadas para la ejecución de pruebas. Por esta razón, se deben configurar esperas implícitas o explícitas en el código para garantizar que la pantalla cargue completamente, evitando que no se encuentren elementos durante la ejecución. Este problema se resolvió instalando Mocha en el proyecto, lo que permitió que las pruebas se ejecutaran de forma asíncrona, similar a lo que se hizo con Playwright, requiriendo agregar async en los nombres de las funciones y await en la llamada de cada método.
Incluso con la instalación de Mocha, el proyecto enfrentó problemas al ejecutar algunos flujos de prueba, generando resultados falsos positivos, en los que el log indicaba que no se pudo realizar una acción incluso cuando esta se había completado correctamente. Selenium soporta los navegadores Chrome, Firefox, Edge y Safari, pero requiere configuraciones adicionales para este último. Durante la ejecución de pruebas en modo estándar, una prueba que verificaba la adición y eliminación de todos los productos del carrito siempre devolvía un falso positivo porque el framework no podía hacer clic en el último botón para eliminarlo del carrito. En modo headless, esta prueba se ejecutaba sin errores, pero otras que funcionabam normalmente devolvían falsos positivos.
Debido a la falta de soporte nativo, fue necesario agregar Mocha al proyecto para ejecutar las pruebas, Axios para realizar solicitudes y evaluar el tiempo de respuesta de algunas pruebas, y Chai para validaciones más eficientes. La necesidad de importar dependencias externas, junto con el hecho de que incluso las clases nativas de Selenium deben importarse para ser utilizadas, incrementó significativamente el tamaño de los archivos de código. Además, el desarrollo de métodos base para ser reutilizados por otras pruebas y páginas, junto con la inicialización de variables para que cada nueva página heredara el driver de la anterior, aumentó considerablemente la cantidad de líneas de código, como se muestra en la Figura 13.
Figura 13. Cantidad de líneas de código del proyecto poc_selenium [Code Tabs 2024c]
Por su sintaxis simple e intuitiva, Cypress se destacó como la opción más fácil de aprender, generando por esta razón la menor cantidad de líneas de código entre las opciones evaluadas.
Playwright también destacó por su facilidad de aprendizaje, aunque con un grado de complejidad ligeramente mayor que el framework anterior.
Selenium presenta una curva de aprendizaje más pronunciada y, debido a la necesidad de añadir dependencias externas, requiere no solo aprender sobre el framework, sino también sobre las bibliotecas que deben instalarse.
Para garantizar una medición precisa del tiempo, todos los proyectos se codificaron utilizando el mismo lenguaje de programación (Javascript), localmente en la misma máquina y en el navegador Chrome.
Comenzando con Cypress, el tiempo total de ejecución fue de 1 minuto y 17 segundos, con todos las pruebas completadas sin errores. El informe del Cypress Dashboard se muestra ne las Figuras 14, 15 y 16 a continuación.
Figura 14. Ejecución de la suite de prueba del poc_cypress
Figura 15. Ejecución de la suite de prueba del poc_cypress
Figura 16. Ejecución de la suite de prueba del poc_cypress Fuente: https://cloud.cypress.io/projects/xsy89k/runs/1/overview?roarHideRunsWithDiffGroupsAndTags=1
De forma predeterminada, Playwright ejecuta las pruebas en paralelo entre varias instancias, pero, para fines de comparación, se configuró para ejecutarse con una sola instancia, haciéndolo similar a los demás frameworks. El tiempo total fue de 31 segundos, con todas las pruebas completadas sin problemas. El informe nativo de la ejecución se puede ver en las Figuras 17 y 18.
Figura 17. Ejecución de la suite de prueba del poc_playwright
Figura 18. Ejecución de la suite de prueba del poc_playwright
En la ejecución con Selenium, el tiempo fue de aproxidamente 1 minuto, con una prueba que resultó en un falso positivo. El informe generado en la terminal de VS Code se muestra en las Figuras 19 y 20.
Figura 19. Ejecución de la suite de prueba del poc_selenium
Figura 20. Ejecución de la suite de prueba del poc_selenium
Convertiendo el tiempo de ejecución de todas las pruebas a milisegundos para una evaluación más precisa, se observa que, en las pruebas exitosas, Selenium tuvo un mejor rendimiento en velocidad. Sin embargo, no es posible verificar el tiempo de ejecución de la prueba fallida. Cabe destacar que, en los flujos más cortos, las validaciones de Cypress fueron más rápidas que las de Playwright, pero, en los más largos, Playwright mostró un alto rendimiento. La Figura 21 muestra la comparación de los tiempos de ejecución. Las pruebas de Cypress y Playwright se ejecutaron en modo headless, mientras qe las pruebas de Selenium debieron ejecutarse en modo headed, ya que en modo headless varias pruebas que funcionaban correctamente arrojaban errores.
Figura 21. Comparativa del tiempo de ejecución de las pruebas
La Tabla 5 muestra una comparación entre las funcionalidades soportadas por cada framework.
| Playwright | Selenium | Cypress | |
|---|---|---|---|
| Lenguajes soportados | Javascript, Java, C#, Python, Ruby, Typescript | Javascript, Java, C#, Python, Ruby, Typescript, PHP, Perl | Javascript, Typescript |
| Navegadores soportados | Chrome, Edge, Firefox, Safari | Chrome, Edge, Firefox, Safari | Chrome, Edge, Firefox, Safari |
| Frameworks soportados | Jest/ Jasmine, AVA, Mocha, Vitest | Mocha, Jest/ Jasmine, TestNG, JUnit, Cucumber, NUnit | Mocha, Jest/ Jasmine, Cucumber |
| Integración continua | Fácil integración con herramientas CI/CD | Fácil integración con herramientas CI/CD | Fácil integración con herramientas CI/CD |
| Facilidad de uso | Interfaz amigable y requiere poca configuración | Requiere más configuración y tiene una curva de aprendizaje más pronunciada | Interfaz amigable y requiere poca configuración |
| Experiencia al escribir tests | Intuitiva | Moderada | Intuitiva |
| Manipulación del DOM | Fácil | Moderada | Fácil |
| Soporte de la comunidad | Comunidad en crecimiento | Comunidad grande y activa con buena documentación | Comunidad activa con buena documentación |
| Soporte para ejecución headless | Sí | Sí | Sí |
| Ejecución paralela | Soporta ejecución paralela | Soporta ejecución paralela | Soporta ejecución paralela mediante herramientas CI/CD |
| Control de tráfico de red integrado | Sí | No | Sí |
| Complejidad de configuración inicial | Fácil | Requiere más esfuerzo para configurarse | Fácil |
| Soporte para iFrame | Sí | Sí | Soporte mediante plugins como cypress-iframe |
| Driver | No requiere driver | Requiere drivers específicos por navegador (descarga automática desde Selenium 4) | No requiere driver |
| Soporte para múltiples pestañas | Sí | No | Sí |
| Soporte para arrastrar y soltar | Sí | Sí | Sí |
| Librerías de aserción | Mocha, Chai | PyUnit, JUnit, TestNG y cualquier framework adaptado al lenguaje | Mocha/ Chai |
| Informes integrados | Sí | No | Spec por defecto, personalizable |
| Soporte para comunicación entre dominios | Sí | Sí | Sí |
| Funcionalidades de depuración | Herramientas integradas, incluye función para retroceder en la ejecución | No integradas | Herramientas integradas, incluye función para retroceder en la ejecución |
| Esperas automáticas | Sí | No | Sí |
| Dashboard | No | No | Sí, como funcionalidad de pago |
| Captura de fotos y videos | Sí | No integrada, requiere personalización | Sí |
| Costos | Gratuito para proyectos open source, pago para uso comercial | Gratuito en todos los casos de uso | Gratuito para proyectos open source, pago para uso comercial |
Tabla 5. Tabla comparativa
Por su facilidad de uso y configuración, Cypress es recomendado para equipos con testers principiantes que están comenzando en la automatización de pruebas, permitiendo la creación de proyectos que prueban funcionalidades tanto de aplicaciones web como de APIs. Aunque los tests de Cypress no suelen arrojar falsos positivos, es importante destacar que el tiempo de ejecución de pruebas muy extensas tiende a ser elevado, lo cual puede impactar suites de prueba con numerosos tests de gran tamaño.
Playwright se destacó en la mayoría de los criterios, con un buen soporte para múltiples lenguajes de programación, facilidad de aprendizaje, numerosas funcionalidades integradas, rapidez en la ejecución de las pruebas, soporte para pruebas web y API, capacidad para ejecutar pruebas en paralelo por defecto en varios navegadores y simulación de aplicaciones móviles. Esto lo convierte en una excelente opción para la automatización de pruebas independientemente del nivel de experiencia.
Aunque Selenium mostró el mejor rendimiento en tiempo de ejecución y ofrece soporte para el mayor número de lenguajes de programación entre los frameworks evaluados, resultó ser el más complicado de automatizar debido a su mayor dificultad de configuración y aprendizaje. Además, la falta de funcionalidades integradas exige la instalación de numerosas dependencias, lo que hace de Selenium la opción más recomendable para equipos con mayor experiencia en automatización de pruebas.
[ISTQB-CTFL] ISTQB Foundation Level Syllabus, Version 4.0.
Bastos, A.; Rios, E.; Cristalli, R. and Moreira, T. (2007): Base de conhecimento em teste de software. São Paulo: Editora Martins.
França, Emanuel Victor (2023). Automação de testes funcionais para aplicações web: comparativo dos frameworks Cypress e Playwright
Oliveira, T. (2018). Automação de testes: o que é, quando e por que automatizar. https://medium.com/venturus/quais-as-raz%C3%B5es-para-automa%C3%A7%C3%A3o-de-testes-c177cbd9397
Selenium (2023a). The Selenium Browser Automation Project https://www.selenium.dev/documentation/
Selenium (2024a). Selenium https://github.com/SeleniumHQ/selenium
Cypress (2024a). Why Cypress? https://docs.cypress.io/guides/overview/why-cypress
Cypress (2024b). Cypress https://github.com/cypress-io/cypress
Playwright (2024a). Installation https://playwright.dev/docs/intro
Playwright (2024b). Playwright https://github.com/microsoft/playwright
Puppeteer (2024). Puppeteer https://pptr.dev/
Raggo, G. (2023). Puppeteer vs Selenium vs Playwright, a speed comparison https://www.checklyhq.com/blog/puppeteer-vs-selenium-vs-playwright-speed-comparison/
Raggo, G. (2024). Cypress vs Selenium vs Playwright vs Puppeteer speed comparison https://www.checklyhq.com/blog/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison/
Döring, P. and Brueckner K. (2022). Why we favor Playwright over Selenium or Cypress https://medium.com/tech-p7s1/why-favor-playwright-over-selenium-or-cypress-e96df84c08e1
Akhtar, H (2023). Cypress vs Selenium vs Playwright vs Puppeteer: Core Differences https://www.browserstack.com/guide/cypress-vs-selenium-vs-playwright-vs-puppeteer
Pathak, K (2023). Playwright vs Selenium vs Cypress: A Detailed Comparison https://www.lambdatest.com/blog/playwright-vs-selenium-vs-cypress/
NPM Trends: Comparativo del número de descargas Cypress x Playwright x Selenium Webdriver https://npmtrends.com/cypress-vs-playwright-vs-selenium-webdriver Acessado em: 23/04/2024
Tutorials Point (2020): Cypress Architecture (Test Automation) https://www.tutorialspoint.com/cypress-architecture-test-automation
Learn Microsoft (2023): O que é o Microsoft Playwright Testing? https://learn.microsoft.com/pt-br/azure/playwright-testing/overview-what-is-microsoft-playwright-testing
Code Tabs (2024a): Cantidad de líneas de código del proyecto Poc Cypress https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_cypress
Code Tabs (2024b): Cantidad de líneas de código del proyecto Poc Playwright https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_playwright
Code Tabs (2024c): Cantidad de líneas de código del proyecto Poc Selenium https://api.codetabs.com/v1/loc/?github=AndradeTC86/poc_selenium
Footnotes
-
Puppeteer es una biblioteca de Javascript que proporciona una API de alto nivel para controlar Chrome o Firefox a través del protocolo DevTools o WebDriver BiDi. Puppeteer se ejecuta en modo headless de forma predeterminada. [Puppeteer 2024] ↩
-
El Modelo de Objeto de Documento (DOM) es una interfaz de programación para documentos HTML, XML y SVG que proporciona una representación estructurada del documento en forma de árbol. ↩
Adición al artículo:
Después de la finalización del análisis comparativo, se realizó una refactorización en los proyectos de automatización, donde fue posible identificar la causa raíz de las pruebas que estaban fallando con Selenium.
La prueba en cuestión intentaba encontrar el botón por la clase CSS y terminaba fallando, causando un error falso positivo. Se corrigió para utilizar el Id y el problema dejó de ocurrir. Cabe destacar que en los proyectos de Cypress y Playwright no se presentaron errores al usar la clase CSS, lo que evidencia otra limitación de Selenium.
Después de la corrección, fue posible validar el tiempo total empleado en la ejecución de los 3 proyectos.
Playwright continuó con el tiempo de ejecución más rápido, seguido de Selenium con una diferencia de alrededor de 20 segundos más, y Cypress siguió siendo el más lento, tardando el doble de tiempo que Playwright.