Playwright, mocks globales y cero aislamiento: así prueba Réécoute su SPA
El autor de un reproductor de audio en React publica las decisiones detrás de su suite de pruebas: navegador real, base de datos compartida y una suite que corre en 20 segundos.
Réécoute es un reproductor de audio en forma de SPA escrito en React, pensado para grabaciones largas de dos o tres horas, y su desarrollador ha publicado las notas de cómo montó la suite de pruebas automatizadas. La decisión de base es radical: probar la aplicación entera contra un navegador real con Playwright, en lugar de separar el backend del JavaScript del cliente. Son unos 20 archivos, cada uno con entre uno y cuatro casos.
Viajes completos, no pasos sueltos
El autor prefiere escribir casos largos que recorran un flujo de usuario de principio a fin antes que pruebas pequeñas para cada paso aislado. En una tienda, dice, escribiría el test que añade un artículo al carrito, se registra, va al pago y compra; los tests especializados existen, pero los considera menos críticos que el recorrido completo.
Los tests no viven en entornos aislados y comparten base de datos. Cada uno crea sus propios objetos, no toca nada que no haya creado él y no limpia nada al terminar: los datos se acumulan. El argumento es que aislar con transacciones resulta complicado con Playwright, levantar un backend por test es lento, y trabajar sobre un subconjunto pequeño de datos no detecta consultas que solo se arrastran cuando hay volumen. Tampoco usa hooks before ni after, solo funciones auxiliares para crear usuarios, bandas y sesiones.
Mocks y velocidad
Cada servicio externo (S3, Stripe, Twilio) tiene su mock global, activado por defecto y compartido por toda la suite. Eso permite correr las pruebas sin conexión a internet. Para casos complicados, sobre todo correos y passkeys, hay rutas de código alternativas que se activan con parámetros o cabeceras HTTP que el backend ignora en las compilaciones de producción. El mock de passkeys es el más elaborado: no consiguió que funcionaran en Chromium sin interfaz, así que montó un cliente falso alrededor del crate passkey.
En velocidad, activa fullyParallel para que los tests de un mismo archivo corran en paralelo, y limita la ejecución a Chromium en vez de los tres o cuatro navegadores que Playwright usa por defecto. La suite completa tarda poco más de 20 segundos en un MacBook Air M3 sin ventilador.
La fiabilidad es el punto débil: cuanto más grande es la suite, más frágil se vuelve en conjunto, así que en integración continua configura la opción de reintentos a 2. Dice que podría eliminar los fallos intermitentes con unas horas de trabajo, pero que ahora mismo no le compensa. Para escribir tira de la interfaz interactiva de Playwright.
El interés está en las decisiones, no en el código, que no es abierto. Son atajos que se apartan de la ortodoxia del aislamiento entre pruebas y aun así le funcionan en una aplicación donde nada es público.
