El estado de las pruebas de JavaScript en 2025

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

¿Hemos estado atrapados en los mismos bucles de dolor de pruebas durante años? ¡Aunque pueda parecerlo, no lo hemos estado!

Incluso si AI ahora está escribiendo nuestras pruebas, muchos desarrolladores de JavaScript han enfrentado numerosos desafíos, desde la falta de claridad en las clasificaciones de pruebas hasta la lucha de mocking, pruebas de integración de larga duración y el cambio de todo a pruebas E2E.

Recapitulemos todo lo que ha sucedido en los últimos años y miremos al presente para explorar lo que 2025 traerá para las pruebas en el mundo de JavaScript en torno a los test runners, bibliotecas de pruebas, mocking, prácticas de producción y herramientas basadas en AI.

This talk has been presented at JSNation 2025, check out the latest edition of this JavaScript Conference.

Daniel Afonso
Daniel Afonso
24 min
16 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla profundiza en los desafíos de las pruebas de JavaScript, la diversidad de prácticas de pruebas en las empresas y la evolución de las herramientas de prueba. Explora la transición a pruebas centradas en el usuario, pruebas de componentes basadas en el navegador y avances en herramientas de prueba de AI. El panorama en evolución incluye las características de Playwright y soluciones de prueba integrales. Las tendencias futuras discuten el mocking de red, los avances en pruebas de AI y el papel de AI en las prácticas de pruebas de JavaScript.

1. Exploring JavaScript Testing Challenges

Short description:

La charla comienza cuestionando las razones para probar software y aborda los desafíos comunes de las pruebas. Destaca los puntos problemáticos en las pruebas, incluyendo el mocking, la configuración y el rendimiento. El orador profundiza en los niveles actuales de satisfacción en las pruebas y prepara el escenario para explorar 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.

2. Diving into Company Testing Practices

Short description:

Neofons, un defensor de desarrolladores senior en PagerDuty y parte del equipo de SolidJS DX, explora cómo las empresas están probando. Varias empresas utilizan diferentes herramientas y enfoques de prueba, como BDDs, Jest, Cypress, Karma, Jasmine, Enzyme, y más. La diversidad en las prácticas de prueba entre las empresas muestra el panorama en evolución de las pruebas de software.

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.

3. Exploring Company Testing Evolution

Short description:

Explorando el caso 5 al caso 8 de las prácticas de prueba de la empresa, incluyendo el uso de mock service worker, análisis estático con TypeScript y ESLint, y la evolución de herramientas de prueba de unidad e integración como JestDOM y Enzyme.

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.

4. Navigating Testing Changes in 2019

Short description:

Transición a pruebas centradas en el usuario, adopción de testing library sobre Enzyme, desafíos con la configuración de Jest, introducción de VTest y migración a EpiDOM para pruebas más rápidas.

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.

5. Shifting to Browser-Based Component Testing

Short description:

Influyente post en el blog de Artem sobre entornos de prueba que se asemejan a entornos de ejecución de código, cambio hacia el modo navegador de VTest para pruebas de componentes, y la importancia de probar el código en el navegador como en producción, enfatizando el respaldo de Kent.

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.

6. Evolving Landscape of Testing Solutions

Short description:

La creciente adopción de Playwright y características como Codegen, tracing, capacidades multiplataforma, y el cambio hacia soluciones de prueba integrales que abarcan pruebas visuales, de componentes, API, y accesibilidad. La evolución de las soluciones de extremo a extremo que se expanden más allá de los límites tradicionales, integrando varios aspectos de prueba, y la dirección futura de las prácticas de prueba.

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.

7. Future Trends in Testing Technologies

Short description:

Discutiendo el futuro de las pruebas, la simulación de red con mock service worker, y los avances en herramientas de prueba de IA como Copilot y autoplaywrite para crear pruebas de Playwrite usando lenguaje natural.

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.

8. Advancements in AI Testing

Short description:

Discutiendo el futuro de las pruebas de IA, pruebas auto-reparables, el servidor MCP de playwrite, automatización y diversidad en los enfoques de prueba.

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.

9. Evolving Practices in JavaScript Testing

Short description:

Discutiendo TypeScript y análisis estático, el impacto de VTest en los test runners, la importancia de las pruebas en el desarrollo de código y el futuro papel de la IA en las pruebas.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.