El estado de las pruebas de JavaScript en 2025

Hola, JS Nation. Espero que todos estén teniendo una conferencia increíble hasta ahora. Es un gran placer estar aquí nuevamente con ustedes. Y los invito a pensar en algo. Me gustaría invitarlos a pensar en por qué hacen pruebas. Y esto puede ser porque les da la confianza que necesitan en el código que están escribiendo. Puede ser porque les permite dormir mejor por la noche. Puede ser porque su jefe se los dijo. Bueno, puede que ni siquiera estén haciendo pruebas. ¿Lo están?

Esta es una reflexión que me gustaría tener en mente mientras esta charla avanza porque al final, con suerte, estaremos al tanto de lo que ha estado sucediendo en estos años y hacia dónde vamos en nuestros años de pruebas. Así que me gustaría pensar si alguna vez han tenido alguno de los problemas que están viendo en esta diapositiva sucediéndoles a ustedes. Porque bueno, creo que he pasado por la mayoría de ellos. Y es doloroso. Y cuando comencé a pensar en esta charla, pensé, está bien, tal vez obtengamos algunos datos que puedan respaldar que estos problemas están sucediendo a otras personas. Y bueno, el mejor lugar para obtener eso es en la encuesta del estado de JS, que está abierta ahora mismo mientras estoy grabando esta charla. Así que vayan a llenarla.

Pero sí, este estado de JS nos dice que hay mucho dolor en la simulación, configuración, rendimiento, CSS, CSS, inestabilidad, problemas de pruebas en el navegador. Así que todas estas son cosas que abordaremos en esta charla. Pero este dolor en realidad nos lleva a algo. Nos lleva a que no estamos tan felices como podríamos estar cuando hablamos de pruebas. Ahora mismo estamos en 2.5 de 4, lo cual no es increíble. Me encantan las pruebas. Es como, oh, sí, lo haré. Es probar. Así que decidí tomar estos datos y comenzar a hacer el estado de las pruebas de JavaScript para 2025.

Así que solo para presentarme. Mi nombre es Daniel Afons. Soy un defensor de desarrolladores senior en PagerDuty. Soy parte del equipo soljs.dx. Soy instructor en Egg.io. Soy el autor del libro llamado State Management with React Query.

Y si desean conectarse conmigo, estoy prácticamente en cualquier lugar en línea como danieljcafons. Además de todas estas cosas, también mantengo un boletín llamado This Month in SOLID. Si desean estar actualizados sobre lo que está sucediendo, este mes en SOLID.js. Así que pueden escanear este código QR que están viendo aquí para obtener un poco más de esta información. Entonces, ¿cómo están probando las empresas en 2025? Fue una de las preguntas que me hice. Y una vez más, miré el estado de JS, que me dijo que bueno, la mayoría de las empresas están usando JS. Su Storybook, V-Test, Playwright, Cypress. Así que me da todos estos datos. Pero aún no me enseñó algo. Todavía no me dijo cómo están realmente las empresas usando estas herramientas. Me da las herramientas que las empresas están usando, pero no cómo se están usando. Así que dije, está bien, necesito más datos. Así que básicamente, al principio del año, envié el mismo mensaje a un par de mis amigos, que decía, oye, ¿podrías decirme cómo está probando básicamente tu empresa? Y lo dejé abierto solo para ver qué me dirían. Y hice esta pregunta a ocho personas. Y aquí están los datos que recopilé.

Así que para el caso 1, están haciendo BDD con Playwright, usando JS y la biblioteca de pruebas de React para pruebas unitarias e integración, y Storybook como un catálogo de componentes. La empresa 2 dijo que están usando JS y la biblioteca de pruebas de React para pruebas unitarias/integración y Cypress para end-to-end. Caso 3, están usando Karma y Jasmine para pruebas de integración/componentes, y JS y la biblioteca de pruebas de React para pruebas unitarias, Playwright para pruebas de regresión visual, Playwright para end-to-end, y Storybook como un catálogo de componentes. El caso 4 está usando Jest y Enzyme para integración, y WebDriver I.O. y Cucumber para end-to-end. Así que esto ya nos da algunos patrones. Estamos viendo Jest y la biblioteca de pruebas de React apareciendo para integración unitaria en un poco. Veamos los otros cuatro casos que tenemos. Porque creo que se vuelve mejor aquí en términos de datos, diría yo. Caso 5, Jest y la biblioteca de pruebas de React para integración unitaria, Playwright para end-to-end, y MockServiceWorker/herramienta de simulación personalizada para simular sus solicitudes de API. Y esto me hizo muy feliz, porque esta fue la primera persona que mencionó MSW, y me encanta MSW. El caso 6 está usando Jest y la biblioteca de pruebas de React para integración unitaria. El caso 7 me sorprendió, porque esta fue la primera persona que mencionó TypeScript y ESLint. Así que esta es en realidad la primera persona que mencionó el análisis estático como parte de su suite de pruebas.

Y si conoces el perfil de pruebas, que veremos en un momento, sabes que estos son definitivamente parte de ese alcance. Esta es también la primera persona que mencionó que están usando VTest y la biblioteca de pruebas de React para integración unitaria, además de usar Jest. Y están usando Playwright para end-to-end. Y el caso 8, Cypress para end-to-end, Enzyme slash React testing library para integración unitaria. Entiendo que esto puede ser confuso para algunos de ustedes. La regla que esta empresa está siguiendo es que tienen su base de código antigua en Enzyme, y están migrando cada nueva prueba que escriben, la escriben en la biblioteca de pruebas de React. Y si alguien tiene que tocar una prueba antigua, tienen que refactorizarla. Así es como están haciendo esta migración. Y también están usando MSW.

Así que cuando decidí hacer esta charla, dije, está bien, veamos todos los alcances del trofeo de pruebas, análisis estático, pruebas de integración unitaria y end-to-end. Y hablemos sobre cuál es el estado de ellos para este año. Así que comenzando con el análisis estático. Creo que eso no es una sorpresa para nadie. TypeScript y YesLint están liderando, y continúan siendo el estándar de facto. La migración de TypeScript a Go lo hace aún más rápido, más eficiente. Así que no veo que esto cambie. Sin embargo, hay algunos contendientes por ahí. Y mucha gente está usando Biome u OXLint para reemplazar algunas de estas herramientas. Que son contendientes fuertes, están funcionando bastante bien. Así que el estado del análisis estático en 2025, de una manera muy breve para resumirlo es que TypeScript y YesLint no van a ninguna parte, pero hay estas dos otras herramientas que puedes seguir revisando y averiguando, está bien, tal vez debería usarlas.

Así que ahora vamos a la parte donde creo que vamos a tardar un poco más. Cuando estamos hablando de pruebas unitarias e integración. Porque quiero repasar una línea de tiempo. Hace diez años, todos estábamos usando Karma y Jasmine, y estábamos escribiendo estas pruebas BDD, y lo que realmente llamábamos en ese entonces eran pruebas de componentes. Se ejecutaban en un navegador, y teníamos un problema. El problema era que eran lentas, eran inestables, teníamos problemas con CICD, así que necesitábamos algo mejor. Así que hicimos nuestra primera transición. Y migramos a algo que ahora estaba basado en node. Así que apareció JSDOM, y apareció Jest. Entonces, lo que hace JSDOM es que rellena estas APIs de navegador para que puedan ejecutarse en nodes.

Así que en realidad, ya no tenemos nuestras pruebas ejecutándose en un entorno de navegador. En realidad, las estamos ejecutando en un entorno basado en node. Y esa fue la primera migración que hicimos. Sin embargo, luego necesitábamos algo más. Y esto fue en 2018, y algo sucedió en el mundo de JS, que fue que React hooks salió y también se creó la biblioteca de pruebas. Y con la biblioteca de pruebas vino su filosofía principal, que es que cuanto más se asemejen tus pruebas a la forma en que se usa tu software, más confianza pueden darte. Y esto originó lo que me gusta llamar la falacia del back-end en la categorización del dolor, porque ahora estábamos escribiendo nuestras pruebas centradas en un enfoque centrado en el usuario, y esto comenzó a generar mucha confusión para muchas personas.

No todos ahora sabían qué era una unidad, qué era una integración. Y he trabajado en diferentes empresas desde 2018, y he trabajado con diferentes personas desde 2018, y todos tienen diferentes definiciones en su organización, de lo que es una unidad y lo que es una integración. Y esta es la parte del dolor de categorización. Cuando hablo de la falacia del back-end, la biblioteca de pruebas desafió este punto. La falacia del back-end fue cuando aprendí pruebas, para mí una unidad era algo que se centraba en los detalles de implementación de esa unidad. Y ahora esto estaba siendo desafiado. Así que todas estas cosas, toda esta falacia del back-end y este dolor de categorización hicieron que, esta falacia del back-end hizo que el dolor de categorización fuera peor, porque ahora nuestra unidad ya no era algo que no se centraba en los detalles de implementación. Nuestra unidad era básicamente, podría ser solo un componente único, por ejemplo.

Así que lo hizo todo más complicado. Así que creo que esto es algo importante de mencionar, porque luego hicimos la transición a usar la biblioteca de pruebas. Sin embargo, luego comenzamos a tener otro problema alrededor de 2020, 2021, donde comenzamos a discutir los runners de pruebas y la integración del bundler. Así que no sé ustedes, pero si alguna vez tuvieron que configurar un archivo de webpack para que sus pruebas se ejecutaran y Jest se ejecutara con él, saben que era un infierno de configuración. Y no era solo eso. Jest se ha quedado estancado en el tiempo. Y cuando digo que se ha quedado estancado en el tiempo, solo miren cosas como el soporte de Tyrescript, que es experimental en 2025. Miren cosas como el soporte de ESM, que es experimental en 2025. Mientras tanto, tienes cosas como Storybook 10 que va solo a ESM, y ya están viendo una disminución del 15% en el tamaño del paquete, por lo que lo hace ineficiente. Mientras tanto, el soporte de ESM sigue siendo experimental en Jest. Así que necesitábamos un runner de pruebas que fuera consciente de su entorno, y que funcionara junto con el bundler. En teoría, lo que queremos y necesitamos es construir nuestras pruebas de la misma manera que construimos nuestra aplicación. Así que luego hicimos la siguiente transición, y migramos a VTest, VTest trabajando junto con VTest, e incluso comenzamos a usar esta cosa llamada ApiDom, que es básicamente también construida sobre JestDom. Es Jest.

Básicamente, es más rápido. No, lo siento, es Jest, es JestDom, pero más rápido. Disminuye el uso de ciertas APIs para que sea más rápido, básicamente. Así que todavía está basado en JestDom. Y JestDom es lo siguiente de lo que me gustaría hablar, porque ahora, adentrándonos en estos aquí, Artem, el creador de MockServiceWorker, escribió este increíble artículo en su blog. Puede que sea demasiado largo para la capacidad de atención de hoy, que es de 10 minutos, pero lo hice más corto para ti. Así que en este artículo, Artem explica por qué no usarías el JestDom, y habla sobre el problema de JestDom, lo cual está bien. Se ejecuta en Node, rellena las APIs del navegador, y básicamente ejecuta código similar al del navegador sin un navegador real. Se ejecuta en Node, y tiene esta cita que realmente me encanta. Dice, JestDom se ejecuta en Node, pretende ser un navegador, pero termina no siendo ninguno.

Entonces, ¿qué está proponiendo Artem con esto? Bueno, da otra cita, que dice, cuanto más se asemeje tu entorno de prueba al entorno real donde se ejecuta tu código, más valor te aportarán tus pruebas. Entonces, ¿qué te estoy diciendo? ¿Qué significa esto realmente? Significa, ¿qué, deberíamos volver al navegador? Sí, eso es exactamente lo que te estoy diciendo. VTest introdujo el modo navegador, y estamos volviendo a escribir pruebas de componentes. Y eso es básicamente el siguiente cambio en esto. Y sé que dice experimental, pero lo experimental es solo en el sentido de que algunas de estas APIs podrían cambiar un poco, pero las características principales seguirán siendo las mismas.

Y debo decirte, he estado ejecutando cosas en modo navegador desde abril-marzo de este año, y he estado bastante contento. No he tenido ninguno de los problemas que teníamos antes, porque ahora, en el modo navegador de VTest, estas pruebas ya no son lentas. Obviamente son dos o tres segundos más lentas que las que solo se basan en Node, pero la confianza que tienes, porque ahora las estás ejecutando en un navegador real, puedo lidiar con tres segundos. No son inestables. Y funcionan con CICD, porque puedes simplemente conectarlo y puedes usar cosas como el adaptador de Playwright para que puedas ejecutarlo en tu pipeline. Y sé lo que estás pensando. Así que ahora tengo que hacer una migración completa. Bueno, en realidad no tienes que hacerlo. Es muy, muy simple. Es cuestión de básicamente cambiar dos importaciones, pasando de la biblioteca de pruebas de VTest a VTest browser react, en este caso, y cambiando algunos de los utils. También asegurándote de que tus pruebas ahora sean asincrónicas. Hice esta migración y aprendí que básicamente había cinco pasos que tenía que hacer además de cambiar estas importaciones, lo cual realmente me encanta. El primero, deshazte de cada consulta por find by, porque ahora solo hay get by cuando hablamos de la biblioteca de pruebas. La segunda parte, deshazte de toda la biblioteca de pruebas que esperas, porque ahora todo es asincrónico y tiene reintentos automáticos integrados. Ese es el valor de tener el modo navegador de VTest aquí.

Obviamente, no reintentará para siempre. Tienes los tiempos de espera, pero tiene reintentos automáticos integrados. Así que no tienes que aprovechar estos utils asincrónicos.

El tercer punto fue cambiar mock service worker a modo worker, porque ahora se ejecuta en un navegador. Ya no se ejecuta en el entorno basado en node. Un ajuste allí, el punto cuatro es convertir todas las pruebas en asincrónicas, y el punto cinco, deshazte de todos los mocks innecesarios. Así que ahora no hay necesidad de hacer mocks de cosas como local storage o session storage o lo que sea, porque realmente puedes usarlos en el navegador. Realmente puedes volver a usar las características del navegador en lugar de tener que hacer mocks de cosas que JestDOM probablemente no estaba sintiendo por ti.

Esto me hizo muy, muy, muy feliz. Así que podrías estar pensando, está bien, eso es bastante genial, pero todavía no tengo la confianza de que deberíamos hacerlo. Bueno, si no confías en mí o no confías en Artem, puedes confiar en él. Porque bueno, no puedes. Como se dijo, y él lo dijo, en realidad hice este tweet antes de comenzar a hacer la primera versión de esta charla, lo que me hizo muy feliz que lo hiciera. Nunca he estado tan feliz de ver a la gente desinstalando testing library. Honestamente, es increíblemente gratificante que testing library haya tenido éxito, que haya sido adoptado, reescrito nativamente por Playwright y VTest. Mi trabajo aquí está hecho. Y eso es fantástico, porque si la persona que te dijo en 2018, comencemos a usar esta cosa te está diciendo, tal vez no necesites esta cosa ahora. Volvamos todos al navegador, porque la tecnología funciona para nosotros.

Y esto es como un ¡guau!. Pero así es como se siente estar en el mundo de JavaScript en los últimos años. Recuerden, como en 2020, 2021, todos recordaban cuando hablábamos de frameworks, tal vez deberíamos volver a hacer renderizado del lado del servidor. Y eso es porque la tecnología era mejor. La tecnología nos permitió volver a hacer renderizado del lado del servidor. Y eso es lo mismo que se siente con las pruebas. La tecnología es mejor, está trabajando a nuestro favor. Y ahora podemos hacer pruebas de componentes con la seguridad, la tecnología y el rendimiento que no teníamos hace diez años. Así que, el futuro está en VTest. El futuro está en VTest. Y obviamente, los principios de la testing library todavía están ahí. Pero eso es todo lo que necesitas ahora. Así que, estoy muy emocionado de ver dónde estaremos en dos o tres años. Y si estas migraciones comienzan a suceder.

Así que, a continuación, hablemos de end-to-end. Y creo que, para sorpresa de nadie, Playwright ha estado ganando la adopción. Creo que Playwright ha estado ganando por razones de comunidad. La comunidad de Playwright ha estado creciendo y creciendo y creciendo. Y está siendo cuidada. Está siendo atendida. Y cuando ves a la comunidad crecer y crecer así, eso explica todo el crecimiento que estamos viendo en Playwright. Así que, todavía veo a Cypress y WebDriver ganando, jugando y siendo utilizados. No van a ninguna parte. Pero Playwright, es mi voto para comenzar, y si solo estás eligiendo algo. Y si quieres algo que esté mantenido y tenga muchas cosas listas para usar que no tenías en estos otros dos, Playwright es tu opción. Una cosa que noté, sin embargo, cuando estábamos hablando de cuando estaba investigando para esta charla es que nuestras soluciones end-to-end se están convirtiendo en más que solo end-to-end. Lo que quiero decir con esto es que todos ellos tienen variaciones de pruebas visuales. Todos ellos tienen variaciones de pruebas de componentes. Todos ellos tienen variaciones de pruebas de API. Y todos ellos tienen variaciones de pruebas de accesibilidad.

Y no son solo las herramientas que típicamente asociamos con end-to-end. Storybook. Storybook te permite ejecutar todas estas pruebas también. Esta herramienta que muchos de nosotros solo consideramos como donde podríamos ver nuestros sistemas de diseño, es bastante buena. Y nos permite ejecutar estas pruebas bastante bien también. Así que cuando hablamos de ahora y miramos hacia atrás en nuestro trofeo de pruebas, creo que esto es hacia donde vamos. Y esta es nuestra nueva representación de cómo debería ser un trofeo de pruebas. Todavía tenemos nuestro análisis estático allí, nuestra lógica de unidad allí. Pero ahora estamos ejecutando pruebas de componentes y end-to-end alrededor de este alcance. Y mientras alrededor de todas estas cosas tenemos las pruebas visuales y de accesibilidad. Así que ese es el estado cuando hablamos de este tipo de análisis.

Hablemos de algo más, que es la simulación. Diría que para sorpresa de nadie, espero, es que MSW se ha convertido en la red, la comunidad y el estándar de la industria cuando hablamos de simulación de API para JavaScript. Es bastante genial. GraphQL, WebSocket, para navegador, para Node, React Native, y la comunidad ha estado creciendo y creciendo y creciendo. Y una cosa que me emociona mucho en MSW también es que Artem ha estado trabajando en el soporte para la intercepción de procesos cruzados, lo que significa que vas a poder simular cosas en el servidor y en el cliente, lo que te permite simular cosas como componentes del servidor, funciones del servidor, y en estos casos de uso, lo que lo hace aún más poderoso de lo que ya es y te ahorra mucho tiempo, diría yo. Así que si aún no estás usando MSW para simular tus APIs de red, hazlo.

Así que estamos en 2025, obviamente, y tenemos que hablar sobre IA. Obviamente. Hay una charla en 2025. Necesitamos tener la parte de IA en ella. Y obviamente, Copilot y todas estas herramientas que estamos usando son excelentes compañeros de programación en pareja. Sin embargo, necesitamos asegurarnos de que nuestras fuentes estén siendo verificadas, especialmente si estás adoptando cosas que aún están en fases experimentales o son muy recientes, como las pruebas de componentes y las pruebas, como las pruebas de componentes y el modo navegador de Vitest, porque todas estas son cosas que, bueno, son experimentales en este punto. Así que obviamente, estos modelos podrían no estar entrenados en ello aún. Puedes darles algo de contexto, pero asegúrate de que estás verificando tus fuentes. La IA debería estar allí para complementar tu conocimiento. No debería estar allí para reemplazarlo. Definitivamente te acelerará mucho. Solo asegúrate de que no la estás usando como una forma de no aprender a usar tus herramientas correctamente. El siguiente punto es MCP, y estamos viendo a MCP explotar en el circuito de pruebas mucho.

Playwright tiene soporte MCP, Midscene tiene soporte MCP, ESLint tiene soporte MCP. Entonces, todas estas herramientas están aprovechando MCP, y puedes usarlo para hacer cosas increíbles. En el caso de Playwright, en el caso de Midscene, puedes usarlo básicamente para decirle a tu LLM, oye, ve a este sitio web, realiza este montón de acciones, y luego usa las herramientas que usaste, aprovecha las herramientas que usaste para hacer estas cosas, para generarme una prueba. Y te dará tu prueba, lo cual es bastante, bastante genial. Solo una vez más, asegúrate de verificar si es realmente el resultado o la prueba real que escribirías.

Luego tenemos una pregunta, que es, ¿qué tan lejos estamos de las pruebas de autocuración? Y bueno, en 2024, ya había una empresa que hizo esta increíble publicación en un blog, y ya tenían una versión de cómo se veía la autocuración para ellos. Sin embargo, siento que esto, como la IA, podría estar ya un poco... Como algunas cosas en IA podrían estar ya un poco desactualizadas, porque, bueno, ahora tenemos cosas como AutoPlaywright, CyPrompt y Midscene que te permiten escribir esta prueba, donde solo usas lenguaje natural, y generará tu prueba a partir de ello. Esto es lo más cercano que creo que vamos a estar de la autocuración en pruebas por un tiempo, porque, bueno, dices llenar campo de nombre de usuario, llenar campo de contraseña. El modelo no necesita saber dónde están estas cosas en ese momento. Así que incluso si refactorizas tu página por un tiempo, o si la ajustas, aún las encontrará. Así que estas pruebas podrían recuperarse un poco y podrían ser lo más cercano que llegues a la autocuración.

Sin embargo, una cosa importante a tener en cuenta cuando hablamos de estas cosas es, tienden a ser más lentas, porque aún tienes que ir a cuando todavía estás aprovechando un LLM, todavía aprovechando un modelo, por lo que aún necesita ir y volver para hacer todo el razonamiento, el pensamiento y averiguar dónde están las cosas. Así que estas pruebas podrían tener un costo. Y aquí estos ejemplos están en Midscene, que es construido por ByteDance. Y hablando de ByteDance, también crearon esta cosa llamada UiTars, que es un agente de modelo de código abierto construido sobre un VLM. Así que un VLM es un modelo de lenguaje de visión que integrará razonamiento avanzado habilitado por aprendizaje por refuerzo. Y curiosamente, UiTars es súper poderoso. Esta cosa es incluso mejor jugando Doom que yo, lo cual no soy bueno. Pero cuando tienes una comparación de un LLM versus un VLM, básicamente captura la totalidad de la página y la examina, en lugar de obtener texto mirando una representación de tu HTML o captura de pantalla de cómo se ve tu página y razonando. Esta es la diferencia entre usar un LLM y un VLM para tus pruebas. ByteDance vio algunos escenarios en los que usando UiTars, los prompts no tienen que ser tan descriptivos como cuando estás usando GPT. Sin embargo, cuando estás usando cosas como GPT, son mejores al generar afirmaciones. Así que hay estos pros y contras cuando estamos midiendo cada uno de ellos, diría yo. Así que sí, volviendo a donde estábamos al principio, comenzamos mirando este gráfico que curiosamente decía que el 13% de las personas no prueban. Y si no estás probando, comienza a probar, por favor. Y nos llevó a través de este viaje de preguntarle a un montón de amigos cómo estamos escribiendo nuestras cosas y comenzando a hacer un análisis de dónde estamos y hacia dónde vamos. Así que recapitulemos cuál es el estado actual de las pruebas de JavaScript en 2025. Primero, todos seguirán haciendo sus propias cosas y teniendo diferentes formas de probar. No veo que eso cambie.

A todos les gustan sus opiniones. {{^}}A todos les gusta tener una. Y las pruebas pueden ser extremadamente subjetivas. Así que ten esto en cuenta al iniciar discusiones sobre pruebas. Si realmente estás iniciando discusiones sobre pruebas. Estamos en 2025. No sé dónde está sucediendo esto o si está sucediendo. Pero podría llevar a uno de mis últimos puntos.

Siguiente punto. TypeScript y ESLint son la mejor manera de hacer análisis estático y eso no está cambiando. Vtest trajo un cambio en los ejecutores de pruebas que esperábamos desde hace tiempo. Las pruebas de extremo a extremo están de vuelta y estamos regresando al navegador, baby. Sí, eso sonó extremadamente cursi.

Pero ese es el valor que vamos a obtener de ello. MSW es la solución de facto para la simulación de redes. Las soluciones de extremo a extremo están empujando hacia un conjunto de herramientas de prueba. API, accesibilidad, componente visual, de extremo a extremo. Y estoy interesado en ver qué está sucediendo allí. Porque vimos a muchas empresas en el auge de los componentes del servidor.

Solo decidir escribir pruebas con Playwright. Y ahora con herramientas como Playwright que nos ofrecen toda esta suite. ¿Van estas empresas a siquiera pensar en entrar en Vtest e intentar volver a lo que estábamos haciendo antes? Tengo curiosidad por ver cómo va a progresar esta parte. Al hablar de IA, no solucionará tu brecha de conocimiento. Pero te hará más productivo. Eso es definitivamente algo a tener en cuenta. Y podría llevar a la autocuración, pero a costa de la velocidad.

Y finalmente, todavía siguiendo el primer pensamiento que tuve aquí. Deberíamos dejar de considerar las pruebas como ciudadanos de segunda clase. Deberían ser tan importantes para ti como lo es escribir tu código. Porque las pruebas son las que te garantizan que la lógica de negocio y el valor que tu código está construyendo realmente están ahí. Así que no más no tengo tiempo para probar o no más cómo puedo justificar a alguien de mi equipo que voy a necesitar tiempo extra para hacer estas cosas o odio las pruebas. Las pruebas son tan importantes como el código que escribes o incluso más.

Así que no más tenerlas como ciudadanos de segunda clase, por favor. Así que sí, con esa cita, todos, me gustaría agradecerles mucho por ver esta charla. Si quieren conectarse conmigo, pueden escanear este código QR. Encuéntrenme prácticamente en cualquier lugar en línea en danieljosephones. Y espero que estén teniendo una gran conferencia y continúen teniendo el resto de una gran. Así que nos vemos por ahí, todos. Que tengan un gran día. Adiós.