El conjunto de pruebas de Preact, un framework moderno para aplicaciones web, ejecuta 1003 tests contra el DOM real del navegador en aproximadamente un segundo. El artículo analiza por qué la mayoría de los test runners populares en el frontend tardan mucho más y qué decisiones técnicas permiten alcanzar esa velocidad.
El punto de partida es una medición cruda: 100.000 iteraciones de un test mínimo de renderizado tardan unos 182 ms en un MacBook Air M1, lo que marca el suelo teórico de rendimiento. Sobre esa base, herramientas veteranas como Mocha (2011) o Jasmine (2008) añaden apenas 35 ms de sobrecarga.
La diferencia respecto a los runners actuales se explica por el aislamiento entre tests. Con la popularización de las promesas y async/await, los test runners comenzaron a crear y destruir un entorno independiente para cada prueba, con el fin de evitar interferencias por mutación de estado global. Esa estrategia aporta robustez, pero tiene un coste elevado en tiempo.
En la práctica, la mayoría de las funciones no dependen de estado compartido, por lo que no necesitan ese nivel de aislamiento. Un test que simplemente verifica la suma de dos números puede tardar 10 ms en un runner sin aislamiento frente a más de un segundo en uno que crea y destruye entornos para cada caso, una diferencia de más de 100 veces.
Para las pruebas sobre el DOM, Preact aplica el mismo principio: en lugar de recrear el documento completo, crea un contenedor único por test con beforeEach y lo elimina con afterEach. En el caso de los hooks, que requieren estado global, el equipo asume la posibilidad de fallos puntuales, ya que estos suelen revelar errores reales en la biblioteca. La estrategia combina así el aislamiento mínimo necesario con la cercanía al uso real por parte de los desarrolladores.