Panel Discussion: Testing

[♪ música sonando – sin letras ♪ [♪ música sonando – sin letras ♪ Me gustaría dar la bienvenida a Tomasz Lakomi, Kenzi Dotz, Iris Schaffer y Sophie Au a nuestro panel. ¿Están todos aquí? ¡Hola! ¡Hola! ¡Ah, excelente!

¡Qué bueno verlos a todos! ¡Hola! ¿Cómo están todos? Sí, no tan mal. Genial, dulce, eso es fantástico. Así que, siento un poco que vuelvo a la cosa de Among Us que se mencionó antes. Siento un poco de impostor aquí, porque escribo pruebas en los proyectos que controlo, pero también he trabajado en muchas agencias, empresas y proyectos diferentes donde las pruebas se encontraron con escepticismo, digámoslo así. Así que, estoy realmente emocionado de escuchar sus opiniones e ideas sobre este tema, porque creo que no fui el único que luchó con esta tensión interna de saber que las pruebas proporcionan un gran valor, pero luego también ver malas prácticas y ver problemas. Así que, ¿podrían todos presentarse rápidamente y decir qué piensan que es el valor número uno de las pruebas? Comencemos con Iris. Está bien, empezaré entonces. Mi nombre es Iris, trabajo en Spotify en Estocolmo, Suecia, y creo que para mí el beneficio número uno sería la calidad para el usuario final, solo asegurando que en cada lanzamiento, sin tener que probar manualmente cada vez, cada función.

Oh sí, he estado allí, lo he hecho, tengo una camiseta. ¿Cuál es tu opinión sobre esto, Sophie? Hola a todos, soy Sophie, soy desarrolladora full-stack front-end en Donut en Berlín, y para mí, creo que lo principal sobre las pruebas, similar a Iris, es saber que lo que realmente estoy enviando a producción funciona, en mi caso especialmente, porque hacemos una aplicación móvil, así que no es como si pudieras simplemente enviar una solución rápida, sino que realmente tienes que hacer un nuevo lanzamiento. Así que, realmente tener confianza en que la aplicación que estamos enviando al usuario funciona y no tenemos que enviar 20 lanzamientos de errores rápidamente después, eso es realmente bueno. Oh, eso suena convincente.

Me gustaría dar la bienvenida a Tomasz Lakomi, Kenzi Dotz, Iris Schaffer y Sophie Au a nuestro panel. ¿Están todos aquí? ¡Hola! ¡Hola! ¡Ah, excelente! ¡Qué bueno verlos a todos! ¡Hola! ¿Cómo están todos? Sí, no tan mal. Genial, dulce, eso es fantástico. Así que, siento que un poco volviendo a la cosa de Among Us que se mencionó antes. Siento que un poco soy el impostor aquí, porque escribo pruebas en los proyectos que controlo, pero también he trabajado en muchas agencias y empresas y proyectos donde las pruebas fueron recibidas con escepticismo, digámoslo así. Así que, estoy realmente emocionado de escuchar sus opiniones e ideas sobre este tema, porque creo que no fui el único que luchó con esta especie de tensión interna de saber que las pruebas proporcionan un gran valor, pero luego también ver malas prácticas y ver problemas.

Oh, eso suena convincente. Tomas, ¿qué hay de ti? Hola a todos, así que mi nombre es Tomasz Rakome, soy un ingeniero senior de front-end en Olex Group, y también grabo videos para Ekhel.io. Y cuando se trata del valor número uno de las pruebas, aparte de las cosas mencionadas por Iris y Sofi, me gustaría decir que las pruebas me hacen dormir mejor por la noche. Porque empujo algo a producción, no tengo que preocuparme durante toda la noche de que se va a romper.

De hecho, empujamos algo a producción hace una hora, y no estoy revisando slack o notificaciones en este momento. Conozco esa sensación y conozco el otro lado de esto. Kent, ¿qué hay de ti? Aprendí un montón de tus charlas y masterclasses sobre pruebas, así que... Sí, gracias. Sí, así que mi nombre es Kent y creé TestingJavascript.com, donde enseño a las personas todo lo que sé sobre pruebas. Y no tengo mucho que agregar a lo que se ha dicho. Una cosa es que comencé con las pruebas con mis bibliotecas de código abierto, porque cada vez que empujaba o quería empujar un lanzamiento, tenía que pasar por esto. Abría la biblioteca en una página y hacía clic por todas partes y simplemente tomaba mucho tiempo para algo que estaba haciendo gratis. Así que me pregunté si podría clonarme y hacer eso con mis clones para poder seguir adelante. Eso es lo que son las pruebas para mí.

Es como mil pequeños kents pasando por todas estas cosas diferentes que siempre hice. Ya veo. Interesante. Así que escuché un montón de razones realmente buenas sobre por qué quiero probar. Pero sé, ten paciencia conmigo, esto fue hace unos años cuando comencé. En realidad, no hace unos años, eso fue hace mucho tiempo. Cuando comencé con las pruebas de software, básicamente tuve que leer un libro realmente grueso y no fue muy divertido. Pero si soy un desarrollador de React que recién comienza, ¿cómo empiezo a escribir pruebas? ¿Cuál es un buen camino? Bueno, voy a empezar por ahí. Así que creo que algo que es importante tener en cuenta con las pruebas es que las pruebas no son nada diferente del desarrollo de software regular. Así que es solo otra cosa para la que estás escribiendo software. Y así tener una idea de lo que es una prueba fundamental es realmente útil. Y básicamente una prueba es un software que te dará algún tipo de notificación cuando las cosas no están funcionando como se esperaba. Y así, sí, como, ¿cómo comienzas? Realmente, la respuesta a esa pregunta es generalmente la misma que, como, ¿cómo aprendo el marco X o cómo, sabes, construyo esta función o lo que sea? Porque no es diferente de cualquier otro software que vas a escribir. Correcto. Pero he visto mucho software por ahí, lo siento, cursos o literatura que básicamente asume que estás comenzando en un proyecto en verde. Pero creo que para la mayoría de las personas, ese no es el caso. La mayoría de las personas aquí viendo ahora probablemente tienen una gran base de código y se preguntan, como, ¿cómo empiezo? Incluso si sé cómo escribir pruebas, que mucho del material por ahí cubre, ¿cómo sé cómo empezar en mi base de código existente? ¿Cómo obtengo el mayor beneficio por mi dinero? ¿Cómo lo descubro? ¿Dónde empiezo?

Entonces, ¿podrían todos presentarse muy rápidamente y decir qué piensan que es el valor número uno de las pruebas? Comencemos con Iris. Está bien, empezaré entonces. Mi nombre es Iris, trabajo en Spotify en Estocolmo, Suecia, y creo que para mí el beneficio número uno sería la calidad para el usuario final, solo asegurando que en cada lanzamiento, sin tener que probar manualmente cada vez, cada función. Oh sí, he estado allí, lo he hecho, tengo una camiseta. ¿Cuál es tu opinión sobre esto, Sophie? Hola a todos, soy Sophie, soy desarrolladora full-stack front-end en Donut en Berlín, y para mí, creo que lo principal sobre las pruebas, similar a Iris, es saber que lo que realmente estoy enviando a producción funciona, en mi caso especialmente, porque hacemos una aplicación móvil, así que no es como si pudieras simplemente enviar una solución rápida, sino que realmente tienes que hacer un nuevo lanzamiento. Así que realmente tener confianza en que la aplicación que estamos enviando al usuario funciona y no tenemos que enviar 20 lanzamientos de errores rápidamente después, eso es realmente bueno. Oh, eso suena convincente. Tomas, ¿qué hay de ti? Hola a todos, mi nombre es Tomasz Rakome, soy ingeniero front-end senior en Olex Group, y también grabo videos para Ekhel.io. Y cuando se trata del valor número uno de las pruebas, aparte de las cosas mencionadas por Iris y Sofi, me gustaría decir que las pruebas me hacen dormir mejor por la noche. Porque empujo algo a producción, no tengo que preocuparme durante toda la noche de que se va a romper. De hecho, empujamos algo a producción hace una hora, y no estoy revisando slack ni notificaciones en este momento. Conozco ese sentimiento y conozco el otro lado de esto. Kent, ¿qué hay de ti? Aprendí un montón de sus charlas y masterclasses sobre pruebas, así que... Sí, gracias. Sí, así que mi nombre es Kent y creé TestingJavascript.com, donde enseño a las personas todo lo que sé sobre pruebas. Y no tengo mucho más que agregar a lo que se ha dicho. Una cosa es que comencé con las pruebas con mis bibliotecas de código abierto, porque cada vez que empujaba o quería empujar un lanzamiento, tenía que pasar por esto. Abría la biblioteca en una página y hacía clic por todas partes y simplemente tomaba mucho tiempo para algo que estaba haciendo gratis. Así que me pregunté si podría clonarme y hacer eso con mis clones para poder seguir adelante. Eso es lo que son las pruebas para mí. Es como mil Kents pasando por todas estas cosas diferentes que siempre hacía. Ya veo. Interesante. Así que escuché un montón de razones realmente buenas sobre por qué quiero probar. Pero sé, aguanta, esto fue hace unos años cuando comencé. En realidad, no hace unos años, eso fue hace mucho tiempo. Cuando comencé con las pruebas de software, básicamente tuve que leer un libro realmente grueso y no fue muy divertido. Pero si soy un desarrollador de React que recién comienza, ¿cómo empiezo a escribir pruebas? ¿Cuál es un buen camino? Bueno, voy a empezar ahí. Así que creo que algo que es importante tener en cuenta con las pruebas es que las pruebas no son nada diferente del desarrollo de software regular. Así que es solo otra cosa para la que estás escribiendo software.

Y simplemente escribir pruebas de extremo a extremo, esencialmente, automatiza esa verificación. Mi recomendación general es, ¿cuál es la parte más crucial de tu aplicación? ¿Es tu botón de pago? No sé, como si estuvieras enviando algunos datos financieros, simplemente escribe una sola prueba de extremo a extremo para la funcionalidad más importante de tu aplicación. Y luego, a partir de ahí, expande y trata de cubrir tanto como sea posible. Y no te quedes atrapado en pruebas unitarias y los 5,000 casos límite. Solo asegúrate de tener una idea general que cubra como el 80% de la funcionalidad.

Y así tener una idea de lo que es una prueba fundamental es realmente útil. Y básicamente una prueba es un software que te dará algún tipo de notificación cuando las cosas no están funcionando como se esperaba. Y así, sí, como, ¿cómo comienzas? Realmente, la respuesta a esa pregunta es generalmente la misma que, como, ¿cómo aprendo el marco X o cómo, sabes, construyo esta función o lo que sea? Porque no es diferente de cualquier otro software que vas a escribir. Correcto. Pero he visto mucho software por ahí, lo siento, cursos o literatura que básicamente asume que estás comenzando en un proyecto en verde. Pero creo que para la mayoría de las personas, ese no es el caso. La mayoría de las personas aquí viendo ahora probablemente tienen una gran base de código y se preguntan, como, ¿cómo empiezo? Incluso si sé cómo escribir pruebas, que mucho del material por ahí cubre, ¿cómo sé cómo empezar en mi base de código existente? ¿Cómo obtengo el mayor beneficio por mi dinero? ¿Cómo lo descubro? ¿Dónde empiezo?

Estoy feliz de tomar esa. Así que en mi experiencia, asumiré que es la aplicación web de React. Las pruebas de extremo a extremo son generalmente mi primera opción, que esencialmente generalmente, incluso si aún no escribes pruebas, tienes a alguien que está verificando que la aplicación funcione. Quiero decir, en el peor de los casos, es el usuario cuando está en producción, pero tienes a alguien que te va a decir, oye, el botón de pago está roto. Y simplemente escribir pruebas de extremo a extremo, esencialmente automatiza esa verificación. Mi recomendación general es, ¿cuál es la parte más crucial de tu aplicación? ¿Es tu botón de pago? No lo sé, como si estás enviando algunos datos financieros, simplemente escribe una sola prueba de extremo a extremo para la funcionalidad más importante de tu aplicación. Y luego, a partir de ahí, expande e intenta cubrir tanto como sea posible. Y no te quedes atrapado en pruebas unitarias y los 5,000 casos límite. Solo asegúrate de tener una idea general que cubra como el 80% de la funcionalidad.

Correcto. Eso suena bien para mí. Y sé que quise hacer eso tantas veces cuando las cosas se rompieron en producción y estaba trabajando con proyectos de clientes y recibías llamadas a horas inusuales de tu gerente de proyecto que luego intenta llamarte mientras intentas dormir. ¿Cómo puedo convencer? Así que ahora que podría ser la persona que dice, OK, veo el problema. Quiero escribir pruebas. Aprendí a escribir pruebas. Y ahora sé por dónde empezar. ¿Cómo convenzo a mi equipo para que, A, se una al esfuerzo? Y B, además, ¿cómo convenzo a mi gerente de que no estoy holgazaneando y no gastando tiempo en algo que no es útil? Puedo tomar esta porque de hecho tengo una publicación en mi blog sobre la misma idea. Así que hay un par de cosas aquí. Primero, no deberías tener que convencer a tu gerente, tu gerente de producto o a nadie, realmente. Porque de la misma manera que no tengo que convencer a mi gerente de que me gustaría usar useState o useEffect o cualquier otro hook de React, considera que las pruebas son parte de la cosa que estoy tratando de entregar. En otras palabras, yo, como ingeniero de software, estoy siendo pagado no solo para construir y enviar software, sino también para enviar software que realmente funcione y aporte valor a nuestros usuarios. Idealmente, me encantaría que me pagaran por enviar software roto, pero así no es como funciona el mundo.

Derecha. Eso suena bien para mí. Y sé que quise hacer eso tantas veces cuando las cosas se rompieron en producción y estaba trabajando con proyectos de clientes y recibes llamadas a horas inusuales de tu gerente de proyecto que luego intenta llamarte mientras intentas dormir. ¿Cómo puedo convencer? Así que ahora que podría ser la persona que dice, OK, veo el problema. Quiero escribir pruebas. Aprendí a escribir pruebas. Y ahora sé por dónde empezar. ¿Cómo convenzo a mi equipo para que, A, se una al esfuerzo? Y B, además, ¿cómo convenzo a mi gerente de que no estoy holgazaneando y no gastando tiempo en algo que no es útil? Puedo tomar esta porque de hecho tengo una publicación en el blog sobre la misma idea. Así que hay un par de cosas aquí. Primero, no deberías tener que convencer a tu gerente, tu gerente de producto o a nadie, realmente. Porque de la misma manera que no tengo que convencer a mi gerente de que me gustaría usar useState o useEffect o cualquier otro hook de React, considera que las pruebas son parte de lo que estoy tratando de entregar. En otras palabras, yo, como ingeniero de software, estoy siendo pagado no solo para construir y enviar software, sino también para enviar software que realmente funcione y aporte valor a nuestros usuarios. Idealmente, me encantaría que me pagaran por enviar software roto, pero así no es como funciona el mundo. Pero en un escenario más realista, en el que tienes una base de código heredada y nadie está escribiendo pruebas y te gustaría crear esta configuración de pruebas y allanar el camino para las futuras generaciones que se unirán a este proyecto, me gustaría comenzar por convencer a nuestros gerentes o gerentes de producto o a cualquiera de cuánto tiempo desperdiciamos resolviendo problemas de producción y cuántos de esos problemas de producción podrían haberse evitado si simplemente tuviéramos una prueba de extremo a extremo o algunas otras pruebas, pruebas unitarias, y así sucesivamente. Porque, por ejemplo, considera un sitio web como Twitter. Si en Twitter la página de inicio de sesión está rota, literalmente no puedes hacer nada porque si estás bloqueado de Twitter, como Twitter no es realmente- Quiero decir, puedes, por supuesto, leer los Tweets, pero no puedes tuitear, no puedes agregar nada a la plataforma. Y con solo esta prueba en su lugar, puedes asegurarte de que- Por cierto, estamos absolutamente convencidos de que una gran parte de nuestro sitio web es al menos accesible para nuestros usuarios. Así que comienza no con el hecho de que quiero escribir pruebas, sino habla en su lugar sobre que quiero asegurar la calidad de nuestro software. Porque la gente tiene miedo de la palabra prueba, pero tienden a gustarles un poco más la palabra calidad. Bueno, ¿qué pasa si entonces tu gerente pregunta, entonces, ¿por qué estás escribiendo código roto en primer lugar? ¿Verdad? Sé que la respuesta a eso es como, eso es algo que me han preguntado. Claro. Realmente no tenía una respuesta. Claro. Diría que no escribo código roto. Mis colegas, ellos tampoco tienen código roto, pero todos nosotros juntos tendemos a producir algo que puede estar roto. Así que me gustaría decir que todos intentan hacer lo mejor que pueden, pero a veces las cosas simplemente suceden. Y no es culpa de nadie que algo se rompa en producción. Y al tener el mejor proceso en su lugar que podamos, podemos asegurar la máxima calidad de nuestro software en producción.

Pero en un escenario más realista, en el que tienes una base de código legado y nadie está escribiendo pruebas y te gustaría crear esta configuración de pruebas y allanar el camino para las futuras generaciones que se unirán a este proyecto, me gustaría comenzar convenciendo a nuestros gerentes o gerentes de producto o a cualquiera de cuánto tiempo desperdiciamos resolviendo problemas de producción y cuántos de esos problemas de producción podrían haberse evitado si simplemente tuviéramos una prueba de extremo a extremo o algunas otras pruebas, pruebas unitarias, y así sucesivamente. Porque, por ejemplo, considera un sitio web como Twitter. Si en Twitter la página de inicio de sesión está rota, literalmente no puedes hacer nada porque si estás bloqueado de Twitter, como Twitter no es realmente- Quiero decir, por supuesto, puedes leer los Tweets, pero no puedes tuitear, no puedes agregar nada a la plataforma. Y con solo esta prueba en su lugar, puedes asegurarte de que- De acuerdo, por cierto, estamos absolutamente convencidos de que la gran parte de nuestro sitio web es al menos accesible para nuestros usuarios. Así que comienza no con el hecho de que quiero escribir pruebas, sino habla en cambio sobre que quiero asegurar la calidad de nuestro software. Porque la gente tiene miedo de la palabra prueba, pero tienden a gustarles un poco más la palabra calidad.

Bueno, ¿y si entonces tu gerente pregunta, entonces, ¿por qué estás escribiendo código roto en primer lugar? ¿Verdad? Sé que la respuesta a eso es como, eso es algo que me han preguntado. Claro. Realmente no tenía una respuesta. Claro. Diría que no escribo código roto. Mis colegas, ellos tampoco tienen código roto, pero todos nosotros juntos tendemos a producir algo que puede estar roto. Así que me gustaría decir que todos intentan hacer lo mejor que pueden, pero a veces las cosas simplemente suceden. Y no es culpa de nadie que algo se rompa en producción. Y al tener el mejor proceso en su lugar que podamos, podemos asegurar la máxima calidad de nuestro software en producción.

Creo que ese es un buen punto. Tener un proceso es clave y es algo que los gerentes también suelen entender porque generalmente ya tienes un proceso al menos para fines de gestión de proyectos o planificación de productos. También debería haber un proceso de garantía de calidad, supongo. Además, otra pregunta interesante que surge es cuando comenzamos a escribir pruebas, especialmente en una base de código legado, pero como la base de código legado también sigue viva y sigue evolucionando, a veces terminas con situaciones donde el sitio web está perfectamente bien. Simplemente las pruebas están fallando. ¿Cómo lidias con eso? ¿Hay algo que puedas... ¿algún patrón que puedas detectar en el código de prueba que quieras probablemente evitar para no terminar en situaciones donde creas pruebas que a veces fallan, a veces pasan sin cambios en el código realizado, o hay pequeños cambios en el código, pero no realmente en la funcionalidad, pero aún así las pruebas ya no pasan? ¿Hay algún anti-patrón que debería estar buscando en mis pruebas?

Además, otra pregunta interesante que surge es cuando comenzamos a escribir pruebas, especialmente en una base de código heredada, pero como la base de código heredada también sigue viva y sigue evolucionando, a veces terminas con situaciones donde el sitio web está perfectamente bien. Simplemente las pruebas están fallando. ¿Cómo lidias con eso? ¿Hay algo que puedas...

¿algún patrón que puedas detectar en el código de prueba que quieras probablemente evitar para no terminar en situaciones donde creas pruebas que a veces fallan, a veces pasan sin cambios en el código realizado, o hay pequeños cambios en el código, pero no realmente en la funcionalidad, pero aún así las pruebas ya no pasan? ¿Hay algún anti-patrón que debería estar buscando en mis pruebas? Creo que puedo tomar esta. Diría que si tienes pruebas que siguen fallando una y otra vez, probablemente estés probando algo que es interno al componente que estás probando, así que en lugar de probar cómo otros componentes se comunican contigo, estás probando algo interno. Tal vez estés probando que esta función está siendo llamada, pero luego cambias qué función está siendo llamada, tu prueba falla, cuando realmente lo que deberías estar probando es, ¿esto se muestra al usuario o se está llamando a esta API? No debería ser el detalle de cómo lo implementas, debería ser el resultado final que deberías estar probando.

Bien, está bien, genial. Y dijiste que un punto válido para comenzar son las pruebas E2E, pero eso plantea la pregunta, ¿qué usas para las pruebas E2E para pruebas de extremo a extremo en aplicaciones web? No sé sobre todos, bueno, conozco la opinión de Tomas sobre esto, pero soy un gran fan de Cypress, he estado usando Cypress durante mucho tiempo, y es fantástico, tiene una gran experiencia para desarrolladores, esa es la razón más grande por la que lo uso, hay Puppeteer, hay Test Café, hay Selenium, y hay varios otros, pero de todo el software de pruebas de extremo a extremo que he usado, Cypress es de lejos el que tiene la mejor experiencia para desarrolladores, y eso es lo que realmente necesitas de una herramienta de prueba, es, sabes, cualquier cosa puede lanzar un error cuando hay un problema, pero no todas las herramientas de prueba son capaces de ayudarte a identificar qué está causando el problema, lo cual es realmente crítico cuando una prueba está fallando. Eso es justo, y una pregunta interesante de seguimiento sobre esto, pruebas de extremo a extremo en navegadores, sé más o menos qué hacer, pero ¿qué pasa si tengo una aplicación móvil? Así que sí, si tienes una aplicación de React Native, así que la única herramienta que estamos usando es Detox. Funciona de manera algo similar a Cypress. Es como súper molesto de configurar. Tengo que admitir, como, creo que nos tomó dos días. La experiencia de desarrollo no es genial, pero una vez que lo haces funcionar, en realidad hace su trabajo bastante bien.

Sí, es una experiencia algo diferente solo porque no tienes un navegador, pero es, como, ejecutándose en el simulador. Pero si recuerdo correctamente, no he escrito en Essence en un tiempo. Pero es como sintácticamente muy similar a Cypress también. Ya veo. Genial. Y con la conversación sobre herramientas de prueba viene algo más porque Ken, ya mencionaste un montón de herramientas. Y tengo al menos la sensación de que similar a los frameworks de JavaScript hace un par de años donde, como, aparecieron como champiñones en otoño en un bosque de Zurich, que hay muchos si no has estado. Creo que, como, las herramientas de prueba también evolucionan bastante rápido.

Diría que si tienes pruebas que siguen fallando una y otra vez, probablemente estés probando algo que es interno al componente que estás probando, así que en lugar de probar cómo otros componentes se comunican contigo, estás probando algo interno. Tal vez estés probando que esta función está siendo llamada, pero luego cambias qué función está siendo llamada, tu prueba falla, cuando realmente lo que deberías estar probando es, ¿esto se muestra al usuario o se está llamando a esta API? No debería ser el detalle de cómo lo implementas, debería ser el resultado final que deberías estar probando. Bien, está bien, genial.

Y dijiste que un punto válido para comenzar son las pruebas E2E, pero eso plantea la pregunta, ¿qué usas para las pruebas E2E para pruebas de extremo a extremo en aplicaciones web? No sé sobre todos, bueno, conozco la opinión de Tomas sobre esto, pero soy un gran fan de Cypress, he estado usando Cypress durante mucho tiempo, y es fantástico, tiene una gran experiencia para el desarrollador, esa es la razón más grande por la que lo uso, hay Puppeteer, hay Test Café, hay Selenium, y hay varios otros, pero de todo el software de pruebas de extremo a extremo que he usado, Cypress es, con mucho, el que tiene la mejor experiencia para el desarrollador, y eso es lo que realmente necesitas de una herramienta de pruebas, es, sabes, cualquier cosa puede lanzar un error cuando hay un problema, pero no todas las herramientas de pruebas son capaces de ayudarte a identificar qué está causando el problema, lo cual es realmente crítico cuando una prueba está fallando.

Eso es justo, y una pregunta interesante de seguimiento sobre esto, pruebas de extremo a extremo en navegadores, sé más o menos qué hacer, pero ¿qué pasa si tengo una aplicación móvil? Así que sí, si tienes una aplicación de React Native, la única herramienta que estamos usando es Detox. Funciona de manera algo similar a Cypress. Es como súper molesto de configurar. Tengo que admitir, como, creo que nos tomó dos días. La experiencia del desarrollador no es genial, pero una vez que lo haces funcionar, en realidad hace su trabajo bastante bien. Sí, es una experiencia algo diferente solo porque no tienes un navegador, pero es, como, ejecutándose en el simulador. Pero si recuerdo correctamente, no he escrito en Essence en un tiempo. Pero es como, en términos de sintaxis, muy similar a Cypress también. Ya veo.

Y hay, como, al menos un bazillion, bajillion diferentes ejecutores de pruebas. Y cada par de años, nuestra opinión cambia sobre cuál es el mejor de ellos. Y me siento igual que hace un par de años. Teníamos Selenium y todos estaban felices y luego todos lo odiaron y luego todos saltaron a no puedo ni recordar cómo se llamaban las piezas y partes intermedias. Pero ahora estamos en Cyprus. Una vez que te comprometes a una solución, ¿deberías, como, apegarte a ella o deberías, más o menos, como, continuar, evaluar y unirte a la moda? ¿Cuál es tu opinión y experiencia?

Puedo tomar esta. Así que cuando se trata de, como, soluciones de pruebas, en mi humilde opinión, el panorama está un poco asentado, al menos para mí, porque estoy usando Jest. Estoy usando React Testing Library, escrita por Kent, y también estoy usando Cyprus.

Así que estoy, sabes, bastante convencido de que este stack me llevará, sabes, a un gran éxito en el software que estoy construyendo. Pero cuando se trata de seguir esta moda, y sé cuándo se va a lanzar la próxima mejor versión de algo para pruebas de extremo a extremo por ejemplo, no estoy del todo seguro de si deberías saltar a la moda de inmediato. Tiende a pensar en el software de la manera que si algo está resolviendo tus problemas y no tienes ningún inconveniente debido al hecho de que estás usando una cierta biblioteca, no creo que debas necesariamente, sabes, saltar a una mejor solución de pruebas. Aunque si, no sé, en la próxima solución de pruebas será, sabes, dos veces más rápida o la prueba sería escrita por una IA, definitivamente estaría interesado. Justo. Creo que, sí, creo que eso es un buen... Cuantas menos pruebas tenga que escribir para estar seguro en mi software, mejor. Exactamente.

No escribo pruebas porque disfrute escribir pruebas. Escribo pruebas porque me gusta poder enviar software y estar seguro de que está funcionando. Así que si no tengo que hacer eso, si no tengo que escribir la prueba, entonces estoy totalmente bien usando alguna IA que lo haga por mí.

Sí, lo mismo ocurre con AngularCode, para que conste. Sí, eso también. Eso es cierto, sí.

Creo que todos están de acuerdo en eso. Hablando de menos pruebas o menos pruebas, si tengo pruebas unitarias y de integración así como pruebas de extremo a extremo, ¿puedo simplemente eliminar estas solicitudes, Elonate, del chat?

¿Puedo simplemente quedarme con las pruebas de extremo a extremo? Porque son las más cercanas a lo que el cliente realmente interactúa, ¿verdad? Estoy feliz de tomar esa.

En mi experiencia, tu prueba de extremo a extremo nunca va a verificar todos los casos límite. Especialmente cuando se trata de interacciones entre componentes. Si tu prueba de extremo a extremo captura todos los casos límite, eso es A, muy impresionante, y B, el traje probablemente va a correr durante horas porque es realmente difícil averiguar todas las diferentes combinaciones de interacciones de componentes.

Así que no elimines las pruebas, especialmente si pasan y hacen su trabajo, entonces déjalas. Pero cuando se trata de escribir nuevas pruebas, mi cosa general es que opto por más tipo de prueba que pruebas unitarias reales porque rara vez tienes solo un componente en tu pantalla. Siempre se trata de componentes interactuando entre sí.

Entiendo. Genial. Y con la conversación sobre herramientas de prueba viene algo más porque Ken, ya mencionaste un montón de herramientas. Y tengo al menos la sensación de que similar a los Frameworks de JavaScript hace un par de años donde, como, aparecieron como champiñones en otoño en un bosque de Zurich, que hay muchos si no has estado. Creo que, como, las herramientas de prueba también evolucionan bastante rápido. Y hay, como, al menos un bazillion, bajillion diferentes ejecutores de pruebas. Y cada par de años, nuestra opinión cambia sobre cuál es el mejor de ellos. Y siento lo mismo que hace un par de años. Teníamos Selenium y todos estaban felices y luego todos lo odiaron y luego todos saltaron a no puedo ni recordar cómo se llamaban las cosas intermedias. Pero ahora estamos en Cypress. Una vez que te comprometes a una solución, ¿deberías, como, apegarte a ella o deberías, como, continuar, evaluar y saltar al carro? ¿Cuál es tu opinión y experiencia? Puedo tomar esta. Así que cuando se trata de, como, soluciones de prueba, en mi humilde opinión, el panorama está un poco asentado, al menos para mí, porque estoy usando Jest. Estoy usando React Testing Library, escrita por Kent, y también estoy usando Cypress. Así que estoy, sabes, bastante convencido de que este stack me llevará, sabes, a un gran éxito en el software que estoy construyendo. Pero cuando se trata de seguir este carro, y sé cuándo se va a lanzar la próxima mejor versión de algo para pruebas de extremo a extremo por ejemplo, no estoy del todo seguro de si deberías saltar al carro de inmediato. Tiende a pensar en el software de la manera que si algo está resolviendo tus problemas y no tienes ningún problema debido al hecho de que estás usando una cierta biblioteca, no creo que debas necesariamente, sabes, saltar a una mejor solución de prueba. Aunque si, no sé, en la próxima solución de prueba será, sabes, dos veces más rápida o la prueba sería escrita por una IA, definitivamente estaría interesado. Justo. Creo que, sí, creo que eso es un buen... Cuantas menos pruebas tenga que escribir para estar seguro en mi software, mejor. Exactamente. No escribo pruebas porque disfrute escribir pruebas. Escribo pruebas porque me gusta poder enviar software y estar seguro de que está funcionando. Así que si no tengo que hacer eso, si no tengo que escribir la prueba, entonces estoy totalmente bien usando alguna IA que lo haga por mí. Sí, lo mismo ocurre con AngularCode, para que conste. Sí, eso también. Eso es cierto, sí. Creo que todos están de acuerdo en eso. Hablando de menos pruebas o menos pruebas, si tengo pruebas unitarias e integración así como pruebas de extremo a extremo, ¿puedo simplemente eliminar estas solicitudes, Elonate, del chat? ¿Puedo simplemente quedarme con las pruebas de extremo a extremo? Porque son las más cercanas a lo que el cliente realmente interactúa, ¿verdad? Estoy feliz de tomar esa. En mi experiencia, tu prueba de extremo a extremo nunca va a verificar todos los casos límite.

Así que creo que KenTest es realmente bastante un trofeo de pruebas, que son principalmente pruebas de extremo a extremo y luego pruebas de integración y todas esas cosas que son pruebas súper raras. Ahí es cuando haces pruebas unitarias. Generalmente también soy una persona muy perezosa, así que si puedo cubrir todos los casos límite con pruebas de integración, ¿por qué escribiría pruebas unitarias? Eso es solo más código que tengo que escribir y más cosas que tengo que mantener más tarde. Eso es justo. Otra cosa en la que pensar es la inestabilidad. Las pruebas de extremo a extremo tienden a ser un poco inestables a veces porque hay tantos sistemas diferentes en juego. Así que ir a un nivel más bajo ya ayuda mucho con eso porque de repente solo estás probando tu parte de la aplicación en lugar de también la interacción con siete diferentes servicios de back-end. Así que eso puede ayudar. De hecho, también me encantan las pruebas unitarias, pero no las uso tanto para componentes de React sino más para todas mis diferentes funciones que hacen cosas, como todas las cosas de bibliotecas que están simplemente guardadas en algún lugar. Para eso, las pruebas unitarias son perfectamente adecuadas.

En mi experiencia, tu prueba de extremo a extremo nunca va a verificar todos los casos límite. Especialmente cuando se trata de interacciones entre componentes. Si tu prueba de extremo a extremo captura todos los casos límite, eso es A, muy impresionante, y B, el traje probablemente va a correr durante horas porque es realmente difícil averiguar todas las diferentes combinaciones de interacciones de componentes. Así que no elimines las pruebas, especialmente si pasan y hacen su trabajo, entonces déjalas.

Pero cuando se trata de escribir nuevas pruebas, mi cosa general es que opto por más tipo de prueba que pruebas unitarias reales porque muy raramente tienes solo un componente en tu pantalla. Siempre se trata de componentes interactuando entre sí. Así que creo que KenTest es realmente bastante un trofeo de pruebas, que son principalmente pruebas de extremo a extremo y luego pruebas de integración y todas las cosas que son pruebas súper raras. Ahí es cuando haces pruebas unitarias. Generalmente también soy una persona muy perezosa, así que si puedo cubrir todos los casos límite con pruebas de integración, ¿por qué escribiría pruebas unitarias? Eso es solo más código que tengo que escribir y más cosas que tengo que mantener más tarde.

Eso es justo. Otra cosa a considerar es la inestabilidad. Las pruebas de extremo a extremo tienden a ser un poco inestables a veces porque hay tantos sistemas diferentes en juego. Así que ir a un nivel más bajo ya ayuda mucho con eso porque de repente solo estás probando tu parte de la aplicación en lugar de también la interacción con siete diferentes servicios de back-end. Así que eso puede ayudar. De hecho, también me encantan las pruebas unitarias, pero las uso no tanto para componentes de React sino más para todas mis diferentes funciones que hacen cosas, como todas las cosas de la biblioteca que están simplemente guardadas en algún lugar.