Cómo pruebo mis proyectos Svelte

Durante buena parte de mi carrera apenas escribí tests automatizados. Trabajando casi siempre solo, en proyectos que podía probar a mano en un par de minutos, me parecía tiempo mejor invertido en avanzar funcionalidad. Cambié de opinión el día que un cambio aparentemente inocente en un componente compartido rompió un formulario en una página completamente distinta, y no me enteré hasta que me lo dijo un cliente.

Dónde trazo la línea entre Vitest y Playwright

No pruebo todo con la misma herramienta, y tampoco lo intento — cada una responde a una pregunta distinta.

Con Vitest pruebo lógica pura: funciones de formateo de fecha, de dinero, de slugs, cualquier cosa que reciba una entrada y devuelva una salida sin tocar el DOM. Son tests rápidos de escribir y rapidísimos de ejecutar, y son los que escribo casi sin pensarlo según voy añadiendo una función nueva a utils/.

Para componentes .svelte que sí interactúan con el DOM, uso Vitest también, pero en modo navegador con vitest-browser-svelte, montando el componente de verdad en vez de simularlo. Ahí aprendí una cosa por las malas: tras simular un clic o una escritura, hace falta esperar a tick() antes de comprobar el DOM — las runas no actualizan de forma síncrona, y los primeros tests que escribí fallaban de forma intermitente hasta que entendí por qué.

Con Playwright pruebo flujos completos de extremo a extremo: que un formulario se pueda rellenar y enviar de verdad, que la navegación entre páginas funcione, que un elemento crítico no haya desaparecido tras un cambio de estilos. Son más lentos de ejecutar, así que los reservo para los caminos que de verdad me preocupan si se rompen — no intento cubrir cada rincón con este tipo de test.

Lo que no hago

No persigo una cifra de cobertura como objetivo — un cien por cien de cobertura con tests superficiales da una falsa sensación de seguridad, y he visto proyectos con ese número perfecto que igualmente se rompían en producción. Prefiero menos tests, pero que cada uno cubra algo que de verdad me ha fallado alguna vez o que sé que es fácil de romper sin darme cuenta. La lista crece con el tiempo, casi siempre después de un bug que no quiero volver a ver.