El estado de las pruebas de JavaScript en 2025

Hola, JS Nation. Es un verdadero placer estar aquí para dar otra charla. Y no perdamos tiempo y vayamos directo al grano, ¿de acuerdo? Me gustaría comenzar esta charla con una pregunta. Me gustaría invitarte a reflexionar. ¿Por qué probamos? Puede ser por muchas razones. Puede ser porque te gusta dormir mejor por la noche. Puede ser porque las pruebas te dan confianza y hacen que tu software se sienta más resistente. Incluso puede ser porque tu jefe te dijo que tienes que hacerlo. ¿Por qué lo haces? Esta es la pregunta inicial que me gustaría que consideraras y pensaras un poco.

Ahora, me gustaría cambiar de marcha. Me gustaría que... Si esto fuera en persona, te pediría que levantaras la mano. Me gustaría que levantaras la mano virtualmente si alguna de estas situaciones te ha sucedido alguna vez. Si alguna vez tuviste pruebas inestables, si alguna vez tuviste pruebas complejas, si alguna vez tuviste pruebas lentas, falta de soporte ESM, falta de soporte TypeScript, demasiado código repetitivo, el mocking siendo doloroso, las herramientas de prueba siendo difíciles, o las herramientas de prueba siendo difíciles de mantener. Si alguna vez tuviste uno de estos problemas, entonces es muy probable que estés en la mayoría de las personas. Si no has tenido ninguno de estos problemas, entonces ven a hablar conmigo. Realmente estoy muy interesado en ver qué estás probando y cómo estás probando.

Pero cuando decidí comenzar a hacer esta charla, entrevisté a un par de personas, hice algunas investigaciones, y un gran recurso para ayudarme a preparar esta charla fue el estado de JavaScript. Y en el estado de JavaScript, hablamos sobre pruebas. Allí, una de las preguntas fue ¿dónde está nuestro dolor? Y curiosamente, la mayoría de las personas sienten dolor con el mocking, con la configuración, con el rendimiento, con Jest, con ESM y CommonJS, que es algo de lo que hablaremos en un momento. Hay mucho dolor en las pruebas, y esto nos lleva a que nuestros niveles de felicidad no estén del todo allí. Este es un puntaje NPS, estamos alrededor de 2.5 en este momento, nunca hemos alcanzado un 3, así que la gente está satisfecha. Parece que lo que tenemos es suficiente, pero no es perfecto, aún no estamos en el mundo ideal. Así que vamos a dar un paseo, y vamos a averiguar qué sucedió en los últimos años debido al estado de las pruebas de JavaScript en 2025.

Antes de continuar, mi nombre es Neofons, soy un defensor de desarrolladores senior en PagerDuty, soy parte del equipo de SolidJS DX, soy instructor en Egghead.io y escribí un libro llamado State Management with React Query. Además de esto, escribo un boletín cada mes llamado This Month in Solid, donde puedes seguir lo que está sucediendo en el mundo de SolidJS, y acabo de lanzar un curso gratuito en Egghead llamado Getting Started with Solid Start, si quieres echarle un vistazo. Puedes encontrarme en línea en cualquier cuenta llamada DanielGCFons. Así que volvamos a la charla, ¿de acuerdo?

Una de las cosas que realmente, realmente quería saber es cómo las empresas están probando. Y el estado de JS me dio algunas ideas, me dijo que mucha gente está usando JS, mucha gente está usando Storybook, algunas personas ya están usando VTest, Playwright, Cypress, Testing Library, Mocha, Puppeteer, Selenium. Pero estos son datos en bruto, y realmente quería pensar y preguntar a la gente, de acuerdo, ¿cómo están probando? Y me gustaría que esto viniera de personas de diferentes empresas, desde startups hasta empresas de la lista Fortune 500, para averiguar cómo están probando y cómo se ven sus pruebas. Así que entrevisté a 8 personas, y revisemos lo que me dijeron, ¿de acuerdo?

Entonces, la primera empresa me dijo que están usando BDDs, Behavior Driven Development Testing, con Playwright. Están usando Jest y React Testing Library para pruebas unitarias e integración, y están usando Storybook como un catálogo de componentes. La segunda empresa me dijo que están usando Jest y React Testing Library para integración unitaria, Cypress para extremo a extremo. La tercera empresa me dijo que están usando Karma y Jasmine para pruebas de integración y componentes. Y Jest y React Testing Library para unitarias. Playwright para regresiones visuales, Playwright para extremo a extremo, y Storybook como un catálogo de componentes. La cuarta empresa me dijo que están usando Jest y Enzyme para integración, y WebDriverIO con Cucumber para extremo a extremo. ¿Te identificas con alguna de estas empresas ya? ¿Es esto algo que estás experimentando actualmente? Piensa en eso por un momento, mientras vamos a la otra empresa.

Así que cuando llegamos a este caso 5, y eventualmente creo que es el caso 7, las cosas se ponen un poco más interesantes. Porque la pregunta que hice a las personas en estas entrevistas fue muy simple. ¿Podrías simplemente decirme cómo es tu stack de pruebas y qué tipo de pruebas estás escribiendo? ¿Cómo pruebas? Y creo que con el caso 5, es donde escuché por primera vez a la gente mencionar mock service worker. He estado usando mock service worker durante años. Lo abordaremos en esta charla. Pero esta es la primera empresa que me dijo, sí, tenemos Jest y React Testing Library para integración, Playwright para extremo a extremo, pero ahora también estamos usando mock service worker y una herramienta de simulación personalizada para simular nuestras solicitudes de red y otras. Caso 6, Jest y React Testing Library para integración unitaria. Y el caso 7 fue en realidad la primera persona en mencionar el análisis estático. Si estamos hablando del trofeo de pruebas, del cual hablaremos en un momento, el análisis estático es una gran parte de él. Y en este caso 7, están usando TypeScript y ESLint para hacer algo de análisis estático. VTest y React Testing Library para integración unitaria, y Playwright para extremo a extremo. Finalmente, para el caso 8, tenemos Cypress para extremo a extremo, Enzyme y React Testing Library para integración unitaria, y MSW con una herramienta de simulación personalizada, y una herramienta de simulación personalizada. Así que, este es un poco de resumen que abarca 8 empresas diferentes en 8 contextos diferentes. Y es algo muy interesante cuando estaba haciendo esta charla, porque ahora, cuando nos han enseñado el trofeo de pruebas y Kent Cedald nos ha explicado esto, y hemos aprendido esto en los últimos años, siempre pensamos en estos 4 temas, extremo a extremo, integración, unidad, estático, aunque un par de ellos se han vuelto un poco confusos a lo largo de los años, estos han sido los puntos de prueba que nos mantienen seguros. Así que pensé, está bien, usemos estos 4 puntos, el análisis estático, la integración unitaria, y el extremo a extremo para ver cómo estamos haciendo pruebas y cuál es el estándar actual para usar estas cosas.

Así que comencemos con el análisis estático. Comencemos desde abajo y subamos desde allí. Bueno, para sorpresa de nadie, TypeScript y ESLint siguen siendo el estándar para hacer análisis estático. Están más que probados, son resistentes a la batalla, y no veo a nadie diciendo que no quieren usarlos. Si tuviera que darte algo para tener en cuenta y mantener bajo tu radar es revisar Biome y OXC. Hay algunos desarrollos interesantes sucediendo allí desde una perspectiva de análisis estático, y de hecho he visto a un par de personas migrando de ESLint a Biome ya, y algunas organizaciones, así que están aquí, ya están dando a algunas personas decisiones diferentes y pruebas diferentes, así que esta es básicamente mi análisis para la parte de análisis estático.

Ahora, pasemos un poco más de tiempo hablando sobre las pruebas de unidad e integración, porque esta es la que creo que más nos emociona, digamos emocionados. Para eso, quería hacer una línea de tiempo, porque, bueno, hace un par de años estábamos escribiendo pruebas, hace un par de años, hace diez años más o menos, aquí es donde estábamos. Teníamos un montón de pruebas usando Karma y estábamos usando Jasmine, y todas estas eran pruebas de componentes. Estas pruebas se ejecutan en un navegador real, pero teníamos un par de problemas con esto. En primer lugar, estas pruebas no siempre eran confiables, eran un poco inestables, los navegadores siempre se estaban bloqueando, y no hablemos de cómo demonios podíamos llevar esto a una canalización CI-CD. Así que hicimos una transición, y esta transición significó, está bien, ahora no queremos ejecutar cosas en un entorno de navegador, queremos simular un entorno de navegador en un entorno basado en node, así que surgimos con JestDOM, y sobre JestDOM, teníamos Jest, y lo emparejamos con Enzyme, como una biblioteca de pruebas, para escribir nuestras pruebas. Y aquí es donde estábamos alrededor de 2017, 2018, pero en 2018, creo, es cuando algo cambió, y me gustaría llamarlo la falacia del backend y el dolor de la categorización, porque esto es lo que sucedió en 2018. El famoso tweet que cambió la forma en que hacíamos pruebas en el frontend, en el mundo de JavaScript. Cuanto más se parezcan tus pruebas a la forma en que se usa tu software, más confianza pueden darte.

Y esto cambió la forma en que hacíamos nuestras pruebas, porque ahora estábamos enfocados en una perspectiva centrada en el usuario. Y la razón por la que llamo a esto la falacia del backend es porque, bueno, la mayoría de nosotros, incluyéndome a mí, no estábamos probando desde una perspectiva de backend. Así es como hicimos pruebas durante años. Y ahora se nos animaba a omitir los detalles de implementación y solo pensar en ello desde una perspectiva de usuario. Ahora una unidad sería un componente individual, y una integración serían componentes trabajando juntos. Esa es la definición con la que estábamos trabajando, y también se volvió un poco más confuso para un par de personas, porque algunas personas ahora no sabían cómo deberían estar probando, o cómo deberían llamar a sus pruebas. Pero de cualquier manera, lo que sucedió ahora fue que nos alejamos de Enzyme y comenzamos a usar la testing library. Y ahí es donde estábamos en 2019.

Luego surgió otro problema, que fue que tuvimos algunos problemas con nuestros test runners y la integración del bundler. Así que, no sé si recuerdas estos problemas que tuvimos con Jest, pero, bueno, solo voy a nombrar un par de ellos. Fue un gran dolor de cabeza configurarlo, solo para asegurarnos de que todo funcionara. Estaba estancado en el tiempo. ¿Quieres una razón por la que estaba estancado en el tiempo? Solo mira el soporte de TypeScript y el soporte de ESM con Jest, que actualmente, ahora mismo, todavía es experimental con la parte de ESM. ¿Por qué? Bueno, no tengo idea. Así que necesitábamos un test runner que idealmente fuera consciente de su entorno y trabajara junto con su bundler. En lugar de tener que configurar estas cosas nosotros mismos, queríamos construir nuestras pruebas de la misma manera que construimos nuestra aplicación. Y aquí es donde apareció VTest.

Ahora, también hicimos algunos cambios aquí. Nos alejamos de JestDOM a EpiDOM, que, en pocas palabras, es una versión reducida de JestDOM, que está hecha para ser más eficiente, con la desventaja de perder algunas características que teníamos con JestDOM. Pero es más rápido. Nuestras pruebas eran más rápidas. Pero ahora, surgió otro problema, que es el problema de JestDOM. Artem, el creador de mock-service-worker, escribió este increíble post en el blog que realmente recomiendo que revises. Y no lo repasaré, porque solo tengo 20 minutos y actualmente estoy en el minuto 12. Pero creo que una de las grandes cosas sobre este post, y una de mis citas favoritas, es esta. JestDOM se ejecuta en Node.js, pretende ser un navegador, pero termina no siendo ninguno. Porque, en realidad, lo que estamos haciendo allí es, para que tengamos un navegador ejecutándose en un entorno Node, solo estamos rellenando las APIs del navegador. Básicamente estamos creando estas APIs que los entornos Node no tienen en un entorno basado en Node. Así que estamos tratando de ejecutar código similar al de un navegador sin tener ningún navegador. Ese es el problema de JestDOM.

Eso es lo que ha estado sucediendo. Este post en el blog de Artem es realmente, realmente genial. Realmente te recomiendo que lo revises. Pero otra cita, y creo que es la cita que va a moldear, nuevamente, cómo estamos haciendo pruebas, en el front-end, es esta. Cuanto más se parezca tu entorno de prueba al entorno real donde ejecutas el código, más valor te aportarán tus pruebas. Entonces, podrías ver el paralelo con la cita de la testing library, porque es muy similar. Y es realmente cierto. Piénsalo. Ejecutamos nuestro código en el navegador. Entonces, ¿por qué no deberíamos probar nuestro código en el navegador? Vaya, podrías decir, en los días de Karma, todo era inestable, todo se caía, pero ahora tenemos una mejor experiencia. Y es por eso que creemos que lo que viene a continuación es el modo navegador de VTest.

Entonces, el modo navegador de VTest es básicamente lo que dice. Estamos haciendo pruebas de componentes. Estamos llevando todo de vuelta al navegador. Y ahora podrías estar pensando, oh, entonces tengo que ir y refactorizar todo de nuevo, pasar meses y meses y meses haciéndolo. Bueno, no lo haces. Este hilo que hizo Artem, es básicamente solo una cuestión de cambiar dos imports. Tuve un par de otras cosas, pero al final del día, me tomó 20 minutos hacer esto para un conjunto de 50 pruebas. Ahora, sé que podría ser complicado para ti tomar esto y pensar, oh, entonces ahora me estás diciendo que necesito mover mis pruebas de integración de unidades al navegador. Significa que necesito salir de la react testing library o comenzar a hacer otra cosa. Bueno, no solo yo y Artem te lo estamos diciendo. Kent te está diciendo lo mismo.

Entonces, lo que digo aquí es que si confiamos en Kent en ese entonces para ayudarnos a liderar el cambio en cómo estábamos haciendo pruebas, hagámoslo de nuevo. Movamos las cosas de vuelta al navegador. Porque al final del día, y una cosa que he notado es que las pruebas no se vuelven tan lentas. Es una diferencia de un segundo. Y para ser honesto, puedo vivir con una diferencia de un segundo en mis pruebas, considerando que todo lo demás me dará la confianza de que las estoy ejecutando exactamente como mis usuarios están ejecutando su código. Así que, sí, ahí es donde vamos. El futuro está en las pruebas de componentes en lo que respecta a la parte de integración de unidades. Así que ahora demos otro paso y hablemos de extremo a extremo.

Bueno, para sorpresa de nadie, diría que Playwright ha estado ganando esta adopción. Webdriver.io y Cypress todavía tienen muchas empresas que los utilizan. Pero, bueno, ¿qué puedo decir? La comunidad de Playwright y el equipo de Playwright han estado haciendo un trabajo fantástico. Y no es solo eso. Tiene características como Codegen y tracing, que son fantásticas y te ahorran mucho tiempo. Es multiplataforma, multiplataforma, multilenguaje. Si por alguna razón incluso puedes escribir tus pruebas en Python, no entremos en eso. Y también puedes usarlo para probar aplicaciones web móviles.

Así que, y hay un montón de otras cosas allí como el paralelismo gratuito, que era algo que se pagaba en otra solución en el pasado. Hay muchas discusiones allí. Pero de cualquier manera, creo que con respecto a las pruebas de extremo a extremo, lo que veo que está sucediendo es que Playwright sigue ganando más y más interés. Y se está convirtiendo en una de las soluciones más adoptadas para finales de 2025. Un hecho curioso que noté mientras preparaba esta presentación es que las soluciones de extremo a extremo se están convirtiendo en más que solo extremo a extremo. ¿Y qué quiero decir con esto? Bueno, significa que pueden hacer pruebas visuales. Significa que también pueden hacer pruebas de componentes. Playwright hace pruebas de componentes como experimental y Webdriver.io también.

Cypress, creo que es el único que ya lo tiene no experimental. También te permiten hacer pruebas de API. Y te permiten hacer pruebas de accesibilidad. Y no son solo soluciones de extremo a extremo. Storybook, lo que típicamente se conoce como el catálogo de componentes, también te permite hacer esto. Así que veo que las soluciones de extremo a extremo están tratando de entrar en este espacio de desarrolladores tratando de capturar también una parte de, está bien, ¿cómo probamos otras cosas además de extremo a extremo? Intentemos traer algunas de estas cosas a nuestra propia solución. Al final del día, va a depender de cada empresa lo que quieran hacer. Pero creo que esto podría ser hacia donde nos dirigimos y lo que está sucediendo en los próximos años. Tenemos el análisis estático. Tenemos las pruebas unitarias. Ahora llegamos a migrar estas integraciones a pruebas de componentes porque las pruebas de componentes son una forma de integración de cualquier manera. Y tenemos el orient-to-end para el flujo completo. Entre estos segmentos, tenemos visual y accesibilidad.

Pero esto, amigos, es hacia donde creo que se dirigen las pruebas y lo que viene el próximo año. Ahora, con los dos minutos restantes que tengo, vamos a pasar por diez diapositivas.

Simulación. Este es un tema muy interesante porque creo que, para sorpresa de nadie, mock service worker es el estándar para la simulación de red. No creo que haya nada mejor. Soporta REST, soporta GraphQL, soporta WebSocket. Funciona para navegador, Node, React Native. Incluso tiene un gran ecosistema con cosas como MSW AutoMock, que es una herramienta CLI que te permite generar datos simulados a partir de una definición de API abierta para MSW.

Y una de las cosas realmente interesantes que he escuchado mencionar a Artem recientemente en una entrevista que hizo es que están trabajando en la intercepción de procesos cruzados. ¿Qué significa la intercepción de procesos cruzados? Significa que permitirá a los desarrolladores controlar las solicitudes de red a través de diferentes límites de procesos. Entonces, ¿qué significa esto? Significa que te permitirá simular cosas para componentes del servidor. Finalmente podrás averiguar cómo probar estas cosas a un nivel más bajo que solo de extremo a extremo. Eso es realmente, realmente emocionante. Y no puedo esperar a ver qué sigue haciendo mock service worker y qué sigue trayendo Artem para esto. Esta es una biblioteca tan perfecta. Me encanta tanto. Y, sí, vamos a la parte obligatoria de IA.

Así que para IA, para sorpresa de nadie, Copilot nos ha estado ayudando a acelerar las pruebas. Es realmente genial. Nos ahorra mucho tiempo. Es un muy buen compañero de programación en pareja. Solo asegúrate de verificar sus fuentes a veces porque ha habido muchas veces que ha intentado usar información desactualizada. Pero, bueno, es perfecto. Es genial. Otras cosas que también estamos viendo. Así que hay algo llamado autoplaywrite que te permite básicamente usar lenguaje natural para escribir pruebas de playwrite. Así que solo dices haz esto, haz aquello, haz aquello. Y hay algunas herramientas que hacen lo mismo como MeetScene, CodeSept. Solo hay una consideración que debes tener cuando estás escribiendo este tipo de prueba. Las pruebas basadas en IA todavía son más lentas.

Recuerda, este lenguaje aún necesita ser procesado. Todavía necesita ir a tu modelo. Todavía necesita averiguar. Así que todavía hay algo de lentitud asociada con las pruebas generadas por IA. Pero siento que la IA en las pruebas va a seguir mejorando y mejorando y mejorando. ¿Y quién sabe? Eventualmente podríamos llegar a esta realidad de auto-reparación donde nuestras pruebas sean capaces de repararse a sí mismas. Esto es especulación, obviamente. Pero es emocionante ver que esto está en el horizonte.

Y he escuchado a personas hablar sobre eso. Y finalmente, para concluir la parte de IA, playwrite acaba de anunciar su servidor MCP. Esto es realmente, realmente, realmente genial. Te permite conectarte con tu modelo y usar playwrite desde allí. Y esto te permite automatizar tareas. Pero lo más importante, te permite generar pruebas automáticamente. Puedes decirle a tu modelo, oye, ve a esta página. Descubre algunos escenarios de prueba y luego usa los pasos que hiciste para interactuar con la página para generar pruebas. Eso es bastante genial, diría yo.

Así que siento que esta migración podría cambiar un poco. Todavía siento que vamos a seguir usando Jest por mucho tiempo debido al escenario de código heredado y lo que la gente ha estado haciendo y no. Pero soy optimista de que vamos a ver más VTests aumentar en los próximos años. Playwrite va a seguir aumentando. MSW va a seguir aumentando. Y hay algunas otras cosas de las que no hemos hablado en esta charla. Como no test runner. Pero va a ser un año interesante para las pruebas. Y estoy realmente emocionado de ver qué nos muestra la encuesta del estado de Jest el próximo año. Así que para concluir, algunas consideraciones finales. Todos seguirán haciendo sus propias cosas y teniendo diferentes formas de probar. Creo que eso debería ser obvio. Todos prueban de manera diferente.

Cada uno tiene su propia opinión. Deberíamos estar bien con eso. Cada empresa lo hace de manera diferente. En cuanto al análisis estático, TypeScript y TS y el SLint son la mejor manera de hacerlo. Bioman y OXC están en el horizonte. Pero hasta ahora no van a darles competencia de inmediato.

VTest trajo el cambio en los test runners que esperábamos desde hace tiempo. Ahora tenemos test runners que son conscientes del bundler y hacen lo mismo juntos. Las pruebas de componentes están de vuelta. Y estamos cambiando esto de nuevo al navegador. Con suerte, con una mejor experiencia e incluso trabajando con CICD.

MSW es un estándar de facto para el network mocking. Las soluciones de extremo a extremo están empujando hacia un conjunto de herramientas de prueba. Y la IA no solucionará tu brecha de conocimiento. Pero podría hacerte más productivo. Y eventualmente podría llevarnos a la auto-reparación. Pero a costa de la velocidad. Finalmente, mi última declaración para ustedes. Deberíamos dejar de considerar las pruebas como ciudadanos de segunda clase. Las pruebas nos dan la confianza de que son tan importantes como el código que escribimos. He escuchado muchos argumentos sobre por qué no deberíamos hacer pruebas. O por qué incluso deberíamos molestarnos. Bueno, me gusta dormir mejor por la noche. Y creo que las pruebas me dan esta confianza. Y debería hacer lo mismo por ti. Así que, por favor, comienza a dar la misma importancia a tus pruebas que le das a tu código. Así que con eso, gracias a todos. Esta fue la etapa 2025 de las pruebas de JavaScript. Soy Daniel Alfonso, y nos vemos por ahí. Adiós.