Cypress o Playwright: cuál elijo según el equipo (no según la moda)
He montado suites con los dos en un SaaS, un instituto de investigación y un proyecto europeo. Cuándo merece la pena cada uno y por qué migrar rara vez es la respuesta.
Es la pregunta que más me hacen cuando entro en un equipo: ¿migramos a Playwright? Casi siempre la respuesta correcta no es “sí” ni “no”, sino “¿qué problema tienes ahora mismo?”.
He montado y mantenido suites con los dos: con Cypress en un SaaS de gestión de inventario con releases continuas, con Cypress y Playwright en un instituto de investigación sanitaria, y con Playwright en una plataforma de un proyecto europeo. Esto es lo que he visto, sin entusiasmo de fan.
Dónde Playwright gana de calle
Varios navegadores de verdad. Si necesitas cubrir Chromium, Firefox y WebKit, no hay discusión. Playwright los ejecuta con la misma API y sin montajes raros.
Paralelismo sin pagar. Repartir la suite en varios procesos viene de serie. Cuando la suite crece, esto deja de ser un lujo: es la diferencia entre doce minutos y tres.
Varias pestañas, varios dominios, varias sesiones. Todo lo que implique salir del dominio de la aplicación (una pasarela de pago, un login de terceros, un correo de verificación) es mucho más natural.
Esperas menos frágiles. El modelo de espera automática con reintentos hace que los tests intermitentes sean menos frecuentes, y los tests intermitentes son la causa número uno de que un equipo acabe ignorando su propia suite.
La traza. Cuando un test falla en integración continua, poder abrir una traza con capturas, DOM y red de cada paso ahorra tardes enteras de “en mi máquina pasa”.
Dónde Cypress sigue teniendo sentido
Si ya tienes una suite grande que funciona. Migrar cientos de tests que hoy pasan, para obtener lo mismo que ya tienes, es gastar semanas en algo que el negocio no nota. Ese tiempo casi siempre rinde más cubriendo casos que hoy no se prueban.
Para desarrollo en vivo. Su modo interactivo, viendo la aplicación reaccionar a cada paso mientras escribes el test, sigue siendo muy cómodo para quien está aprendiendo a automatizar.
Cuando el equipo ya lo domina. La herramienta que tu equipo sabe mantener vale más que la mejor herramienta que nadie va a tocar. Esto no es pereza: es lo que decide si la suite sigue viva dentro de seis meses.
La pregunta que de verdad importa
En los equipos donde he entrado, el problema casi nunca era la herramienta. Era alguno de estos:
- La suite tarda demasiado, así que se lanza “cuando toca” y no en cada cambio. Eso se arregla con paralelismo y borrando tests redundantes, no cambiando de herramienta.
- Hay tests intermitentes y el equipo ya no distingue un fallo real de uno de siempre. Eso se arregla atacando las esperas y los datos de prueba.
- Se prueba lo fácil, no lo que duele. Veinte tests del formulario de búsqueda y ninguno del proceso de pago.
- Los tests no están en el pipeline. Si hay que lanzarlos a mano, no existen.
Ninguno de esos cuatro problemas lo resuelve una migración.
Qué hago yo cuando entro
Miro qué hay, lo dejo corriendo en integración continua y añado valor donde no lo hay, con la herramienta que el equipo ya usa. Si aparece un motivo real para cambiar (necesidad de WebKit, tiempos que no bajan, pruebas entre dominios), propongo migrar lo nuevo a Playwright y dejar lo viejo donde está, conviviendo. Las migraciones grandes de golpe suelen acabar en dos suites a medias.
Y mi criterio para un proyecto nuevo, sin historia: Playwright. Por el paralelismo, por las trazas y porque el mismo código me sirve para navegadores de escritorio y de móvil.
Dicho esto, con TypeScript y buenas prácticas, el 80 % de lo que hace bueno a un test —qué prueba, cómo espera, qué datos usa, si alguien lo mantiene— no depende de cuál de los dos elijas.