Cómo se prueba sola esta web (Playwright en CI, sin dramas)

Esta web se prueba a sí misma. No es una frase de marketing: cada vez que cambio algo, una suite de Playwright levanta el sitio compilado y lo recorre en escritorio y en móvil antes de que nada llegue a producción. Si algo falla, el cambio no sale.

Cuento cómo está montado, porque es exactamente lo que hago cuando entro en el equipo de otro: empezar pequeño, probar lo que duele si se rompe, y dejarlo corriendo solo.

Qué pruebo (y por qué esas cosas)

La tentación cuando montas una suite es probarlo todo. Es la mejor forma de acabar con tests lentos, frágiles y que nadie mantiene. Yo empiezo por lo que cuesta dinero o credibilidad si se rompe:

• Que se pueda contactar. El formulario valida, envía y muestra la confirmación. Si esto se rompe, la web deja de servir para lo único que tiene que hacer.
• Que la navegación lleve donde dice. Cada enlace del menú aterriza en su sección y la marca como activa.
• Que Google pueda leerla. Un solo h1 por página, títulos y descripciones con longitud razonable, canonical y hreflang coherentes, y todas las URLs del sitemap respondiendo 200 sin ser noindex.
• Que se lea. Ningún texto por debajo de 12 px, ningún botón por debajo de 24 px de alto y ninguna sección que obligue a un scroll infinito.
• Que cumpla contraste. Con axe-core, en claro y en oscuro, exigiendo AAA (7:1), que es más de lo que pide la ley.

Y hay una categoría que a mí me ha salvado varias veces: los errores de consola. Un test que carga la home y falla si aparece un solo error en consola detecta cosas que ninguna revisión visual ve.

Lo que aprendí montando esto

Un test que no falla nunca no está probando nada. Cuando escribo una comprobación, la rompo a propósito una vez para ver si salta. Si no salta, el test está mal, no el código.

Los fallos más caros son los silenciosos. Montando el sistema de animaciones descubrí que el minificador de CSS reescribía una propiedad de forma que el navegador la descartaba entera: ninguna animación se aplicaba y no había ningún error en ninguna parte. Lo detectó un test que comprobaba que la animación existía de verdad en el navegador, no que el CSS estuviera escrito.

Lo mismo con la accesibilidad: un texto a media opacidad mientras entra en pantalla parece inofensivo, pero durante ese trayecto no cumple contraste. Lo cazó la auditoría automática, no mi ojo.

Las capturas mienten menos que las opiniones. Cuando dudo de si algo se ve bien, no discuto: mido. Altura de cada sección en pantallas, tamaño real de cada texto, desbordes horizontales de 320 a 1920 px. Con números encima de la mesa, las decisiones de diseño dejan de ser una cuestión de gustos.

Cómo corre solo

La suite se ejecuta en GitHub Actions en cada cambio: instala dependencias, compila el sitio, levanta el servidor de vista previa y pasa los tests en Chromium de escritorio y de móvil. Si algo falla, sube el informe de Playwright como artefacto para poder ver la traza.

No hace falta más para empezar. Nada de infraestructura complicada: un fichero de flujo de trabajo y una suite que tarde poco. Si tarda mucho, la gente deja de esperarla, y una suite que nadie espera es una suite muerta.

Si estás pensando en montarlo en tu producto

El orden que sigo cuando entro en un equipo sin proceso de QA:

1. Una semana mirando. Qué se rompe más, qué se prueba a mano antes de cada release, qué da miedo tocar.
2. Cinco o seis tests, no cincuenta. Los caminos por los que pasa el dinero: registro, login, compra, formulario, exportación.
3. Integrarlos en el pipeline el primer día. Un test que hay que lanzar a mano no existe.
4. Estabilizarlos antes de crecer. Un test intermitente es peor que no tener test: enseña al equipo a ignorar la luz roja.
5. Documentar y entregar. Si cuando yo me voy nadie sabe mantenerla, el trabajo no valía nada.

Es el mismo método que apliqué en un SaaS de retail, en un instituto de investigación sanitaria y en un proyecto europeo. Cambia el dominio, no la forma de trabajar.