Desarrollo Efectivo de Pruebas

Rate this content
Bookmark

Los desarrolladores quieren dormir tranquilos sabiendo que no rompieron la producción. Las empresas quieren ser eficientes para satisfacer las necesidades de sus clientes más rápido y obtener ventaja competitiva más temprano. TODOS queremos ser rentables... o debería decir... ¡EFECTIVOS EN LAS PRUEBAS!

  • Pero, ¿cómo lo logramos?
  • ¿Los términos "unitario" e "integración" nos sirven correctamente?
  • ¿O es hora de un cambio? ¿Cuándo debemos usar cada estrategia para maximizar nuestra "efectividad en las pruebas"?

En esta charla te mostraré una nueva forma de pensar en las pruebas rentables con nuevas estrategias y nuevos términos de prueba.

¡Es hora de ir MÁS PROFUNDO!

31 min
18 Nov, 2021

Video Summary and Transcription

Esta charla presenta el Desarrollo Efectivo de Pruebas, un nuevo enfoque para las pruebas que tiene como objetivo hacer que las empresas sean más rentables. El orador comparte su viaje personal de mejorar la calidad del código y reducir los errores a través de estrategias de prueba más inteligentes. Se discute la importancia de encontrar un equilibrio entre la confianza en las pruebas y la eficiencia, y se presentan los conceptos de pruebas aisladas e integradas. El orador también sugiere diferentes estrategias de prueba basadas en el tamaño de la aplicación y enfatiza la necesidad de elegir enfoques de prueba rentables según los requisitos específicos del proyecto.

Available in English

1. Introducción a Test Effective Development

Short description:

¡Hola a todos! Bienvenidos a la charla de introducción a Test Effective Development. Soy Shai Reznick, el chico de Test Effective. Hoy les enseñaré una nueva forma de pensar sobre las pruebas que cambiará su vida de pruebas para siempre. Comencemos. Mi objetivo es ayudar a las empresas ocupadas a ser más rentables a través de la transformación de las pruebas. Integraremos las pruebas en su día a día para que puedan realizar cambios sin introducir nuevos errores. Realicen el cuestionario para descubrir sus mayores errores en las pruebas y obtener recursos gratuitos.

Soy Shai Reznick y hoy les enseñaré una nueva forma de pensar sobre las pruebas que cambiará su vida de pruebas para siempre y aumentará su productividad. Así que comencemos.

Como dije, soy Shai Reznick. Soy conocido como el chico de Test Effective y a veces también como el chico de Angular Testing. También soy un Google Developer Expert y fundé HiRise.IO, que es una empresa de educación y capacitación que enseña a los desarrolladores cómo escribir pruebas más rentables de una manera divertida y entretenida. Además, mis charlas han sido vistas por más de 170,000 desarrolladores y algunas personas al azar. Supongo. Hola, WSI aquí.

De acuerdo. Mi objetivo principal en la vida es ayudar a las empresas ocupadas a ser más rentables a través de la transformación de las pruebas. Eso significa que tomamos su empresa ocupada con su horario, sin detener el desarrollo, y encontramos una forma de integrar las pruebas en su día a día. Si estás interesado en eso, avísame. De acuerdo, podríamos llevar a tus desarrolladores de dormir así a dormir así, donde, como me gusta decir, prueba bien, duerme tranquilo. De acuerdo. Y no solo se trata de dormir tranquilo por la noche, también se trata de ser más profesional. Así podrás realizar cambios en tu código o aplicar esta nueva técnica que aprendas sin el temor de introducir nuevos errores en producción. Y si quieres descubrir tus mayores errores en las pruebas, he preparado un cuestionario, algunas preguntas que puedes responder, y te mostraremos cuáles son tus errores y cómo solucionarlos, y compartiremos contigo algunos recursos gratuitos nuevos sobre las pruebas. Así que revisa este enlace o este código QR, te llevará al mismo enlace y accede al cuestionario.

2. Wi-Fi Disclaimer

Short description:

Hoy no voy a hacer la charla loca por la que soy conocido debido a un problema de Wi-Fi. Estamos compartiendo la señal con los vecinos y puede haber fallas. Así que me limitaré a una charla educativa. Comencemos.

De acuerdo. Ahora un descargo de responsabilidad. Así que soy conocido, si buscas mi nombre en YouTube, es posible que encuentres charlas locas mías, como, ya sabes, a veces es una obra de teatro y a veces es un programa de juegos o una canción de rap o un espectáculo de magia sobre pruebas o uno de mis favoritos personales. Esta es una charla que hice en 2018, donde conecté un dispositivo que puede leer mentes y comparto con la audiencia mi proceso de pensamiento y todas las travesuras que pasan por mi cabeza mientras pruebo una aplicación. Así que incluso si no eres un desarrollador de Angular, encontrarás valor en esta conferencia, así que échale un vistazo. ¡Pero! Así que hoy no voy a hacer esta charla loca porque tengo una situación extraña aquí. Tenemos un problema con nuestro Wi-Fi. Estamos compartiendo la señal de Wi-Fi con todos los demás vecinos aquí en el edificio de oficinas y hoy hay un fenómeno extraño en el que, ya sabes, la gente está pasando por encima de las transmisiones de otras personas, por lo que es posible que veas fallas o que veas lo que otros vecinos míos están viendo aquí. Así que lamento eso. Me disculpo de antemano por cualquier cosa que puedas ver. ¿De acuerdo? No quería, por eso no quería hacer una charla loca hoy porque no sé cuándo ocurrirán estas interrupciones en la transmisión. Así que me limitaré a la charla educativa de toda la vida y ya está. Así que este es el descargo de responsabilidad. Lo siento por eso. Y esperemos, esperemos que tengamos un proceso fluido. De acuerdo, genial. Así que ahora comencemos.

3. The Circle of Doom

Short description:

En 2009, estaba corriendo para cumplir con los plazos, produciendo una mala calidad de código y errores inesperados. Esto llevó a la frustración, ataques de pánico y una sensación de estar abrumado. Fue un lugar realmente aterrador en mi vida.

De acuerdo. Así que en 2009, era un desarrollador en mi trabajo diurno y tenía un proyecto paralelo por la noche. Así que trabajaba de nueve a cinco en el trabajo diurno y hasta las 2 a. m. en la startup. Y así eran mis días. Y estaba en lo que llamo el círculo del terror porque me apresuraba e intentaba cumplir con todos los plazos y avanzar rápido, produciendo una mala calidad de código que generaba errores inesperados, que a su vez generaban más mala calidad de código debido al miedo a los errores inesperados. Me asusté mucho, de acuerdo. Y no quería cambiar ni mejorar el código y eso me llevó a la frustración y a intentar destruir la computadora o no sé, y eso me llevó aún a un lugar más aterrador donde sentía que estaba en un pantano movedizo donde cada vez que solucionaba los errores, introducía cuatro errores más en la aplicación. Y sentía que me estaba hundiendo cada vez más en el pantano movedizo. Y empecé a tener mareos y, y, eh, no podía respirar y estos ataques y no sabía qué me pasaba, así que fui, de hecho fui al hospital y me hicieron chequeos cuando se volvió más grave. Y en realidad me dijeron que no tenía nada físicamente mal. Y sugirieron que podría tener ataques de pánico y así fue. Esto es lo que tenía, ataques de pánico por no cumplir con los plazos. Y, ya sabes, no cumplir con los plazos y tener más errores para solucionar y no saber, tener esta incertidumbre sobre cuándo aparecerán más errores y, fue realmente un lugar aterrador en mi vida.

4. The Journey to a Better Approach

Short description:

Decidí trabajar de manera más inteligente, no más difícil, para tener una vida equilibrada y evitar errores inesperados. Comencé con pruebas unitarias pero me di cuenta de que no eran suficientes, así que probé con pruebas de integración. Sin embargo, eran difíciles debido a la complejidad de los caminos del código. Esta falta de confianza me llevó a buscar un enfoque mejor.

Entonces decidí que necesitaba trabajar de manera más inteligente, no más difícil, porque pensé, ¿qué es lo que realmente quiero en mi vida profesional? Quiero hacer un trabajo significativo. Quiero mejorar mis habilidades y quiero llevar una vida equilibrada. No quiero perderme las vacaciones, los cumpleaños o pasar tiempo con mi familia y amigos, en ese entonces mi novia, y lo que me impedía hacer todo eso eran los errores inesperados. Así que decidí aprender cómo solucionarlos y hablar con amigos y sugerirnos escribir pruebas.

Así que comencé a aprender sobre las pruebas y me encontré con términos extraños, como pruebas unitarias e integración, y no sabía cuándo elegir cada una. Y en algún lugar leí que las pruebas unitarias son para los desarrolladores y las pruebas de integración y de extremo a extremo son para el control de calidad. Así que decidí comenzar con las pruebas unitarias. Al principio fue difícil entender qué estaba haciendo, pero con el tiempo fui mejorando. Pensé que lo tenía dominado. Pero luego, aunque tenía una cobertura del 100% o del 90%, seguía teniendo errores en producción. Me di cuenta de que las pruebas unitarias no eran suficientes. También necesitaba pruebas de integración.

Así que lo intenté, realmente lo intenté. Intenté escribir pruebas de integración y al principio fue muy difícil, pero al final seguía siendo difícil porque las pruebas de integración son muy complicadas. Parecían fáciles al principio, pero cuando te das cuenta de que tienes mucha lógica y piezas móviles en tu código, y toda esta complejidad psicométrica y otros términos que te hacen sonar más inteligente de lo que eres, pero básicamente significa que tienes muchos caminos de código en tu aplicación, puntos de decisión y cosas así, lo que dificulta mucho las pruebas de integración y las hace más lentas de ejecutar. Esto me llevó a escribir pruebas solo para el flujo principal cuando las cosas son exitosas y no para verificar situaciones de error, cosas así. Esto hizo que tuviera menos confianza en mis pruebas de integración porque me di cuenta de que era solo una ilusión. No me daban plena confianza en mi código. Siempre sentía que esta manta era demasiado corta, cada vez que intentaba usar una nueva técnica, ya sea de integración o unitaria, siempre sufría por algo más. Después de unos años de pruebas, me convertí en consultor de pruebas y ayudé a las empresas con su código. Les enseñé las mismas formas tradicionales, como la pirámide de pruebas y todas esas cosas. Pero me frustré porque no obtuve los resultados que quería tener. Y esta soy yo, frustrada. Llegué a la conclusión de que ya era suficiente. Necesitamos un enfoque nuevo. Necesitamos una mejor manera de hacer las cosas.

5. Strategies for Testing Confidence and Efficiency

Short description:

Comencé a experimentar con estrategias y tuve epifanías que llevaron a nuevas estrategias. Aplicarlas a mi código mejoró mi confianza y eliminó los problemas que enfrentaba con los métodos tradicionales. Me di cuenta de que las pruebas ineficientes también estaban obstaculizando mi progreso. Para manejar errores inesperados, me enfoqué en aumentar la confianza en las pruebas, mientras que para combatir las pruebas ineficientes, era necesario mejorar la eficiencia en las pruebas.

De acuerdo. Así que comencé a experimentar, ya sabes, con estrategias. Y luego, tuve algunas epifanías y aprendí las nuevas estrategias que funcionaron para mí. Y una vez que comencé a aplicarlas en el código de mis clientes y en mi propio código, finalmente llegué al punto en el que puedo cambiar mi código con confianza y no sufro con todas las cosas que sufría cuando usaba los métodos más tradicionales. Y quiero compartir la epifanía que tuve. Porque, como te dije, quiero hacer un trabajo significativo y mejorar mis habilidades y llevar una vida equilibrada. Y lo que pensé, lo único que me impedía hacerlo eran errores inesperados, pero de hecho no eran solo errores inesperados, también eran pruebas ineficientes. Así que, simplemente cambié de perder tiempo en solucionar errores inesperados a perder tiempo en solucionar pruebas ineficientes. Entonces pensé, ¿qué puedo hacer para manejar errores inesperados? Necesito aumentar mi confianza en las pruebas. ¿Y qué puedo hacer para combatir las pruebas ineficientes? Necesito aumentar la eficiencia en las pruebas. Sé que suena obvio, pero es importante saberlo porque ahora que conocemos estos dos factores, podemos verlos y ver nuestras pruebas desde estas perspectivas.

6. Strategies for Test Effectiveness

Short description:

Cuando se trata de estrategias, algunas conducen a una mayor eficiencia pero menos confianza, mientras que otras conducen a una mayor confianza pero menos eficiencia. El objetivo es encontrar un equilibrio entre la confianza y la eficiencia, que defino como ser rentable. El desarrollo de pruebas efectivas busca encontrar mejores términos, estrategias y herramientas para escribir pruebas más rentables. Hoy nos centraremos en dos estrategias. Para ser más efectivos, necesitamos ser más específicos, utilizando la herramienta adecuada para el trabajo. Aplicé el método de pensamiento de primer principio de Elon Musk a la integración de unidades, con el objetivo de encontrar los primeros principios detrás de estos términos y proponer nuevos.

Y si pensamos en las estrategias, herramientas y técnicas que solíamos aplicar o usar en nuestras pruebas, ¿de acuerdo? Ahora, cuando pensamos en la confianza y la eficiencia y las juzgamos por estos términos, podemos ver que algunas estrategias conducen a una mayor eficiencia pero menos confianza, y otras conducen a una mayor confianza pero menos eficiencia, por ejemplo, las pruebas de extremo a extremo, donde tienes mucha confianza porque todas las partes móviles están integradas y pruebas todo en un solo lugar, pero son las pruebas menos eficientes de todas porque se ejecutan más lentamente y requieren más código y fallan con más frecuencia y cosas así.

Entonces, aunque nunca se puede llegar a un punto perfecto al 100%, siempre se sufre de errores. El punto es encontrar un equilibrio. Un equilibrio entre la confianza y la eficiencia que tenemos de una estrategia específica o dos. Entonces pensé, ¿qué puede definir este equilibrio? ¿Cómo puedo usar un solo término para definir este equilibrio entre la confianza y la eficiencia? Y lo único que se me ocurrió fue rentable. ¿Qué tan rentable es esta estrategia? Y luego pensé que era demasiado genérico. Así que seguí pensando en rentable, rentable. Tal vez pueda llamarlo efectividad de pruebas. Y la idea aquí es encontrar mejores términos, mejores estrategias y mejores herramientas para escribir tareas más rentables. Hay muchos temas que cubrir en el desarrollo de pruebas efectivas, pero hoy, debido al tiempo limitado, nos centraremos solo en dos estrategias.

De nuevo, lo que aprendí sobre ser más efectivo en las pruebas es que si quieres ser más efectivo, necesitas ser más específico. Por ejemplo, si quieres hacer una cirugía, quieres ir a un cirujano que sepa cómo usar la herramienta adecuada para el trabajo en el momento adecuado, y no a un maniático con una motosierra que solo sepa cómo usar esta herramienta.

7. Testing Dimensions and Boundaries

Short description:

La idea proviene de Elon Musk y su método de pensamiento de primer principio. Al pensar en la integración de unidades, hay confusión acerca de las definiciones. Decidí profundizar y descubrí nuevas dimensiones de pruebas, como los límites, el alcance de acción y el tipo de sujeto. Hoy nos centraremos en los límites, que se refieren a las pruebas aisladas versus integradas. Las pruebas aisladas significan probar solo una cosa y simular el resto de las dependencias.

Y la idea proviene en realidad de Elon Musk y su método de pensamiento de primer principio, donde lo aplicó a la construcción de cohetes reutilizables yendo hasta los primeros principios e intentando construir soluciones mejores a partir de eso. Eso es lo que apliqué.

Y cuando pensé en la integración de unidades, me dije a mí mismo, okay, intentemos encontrar cuáles son los primeros principios detrás de estos términos e intentemos construirlos nuevamente y tal vez proponer nuevos términos. Okay.

Entonces, cuando piensas en una aplicación, digamos la parte de la aplicación, como clases o funciones o algo así, y la conexión entre ellas, como que se importan entre sí, esto es nuestra aplicación. Okay. Y cuando piensas en las pruebas unitarias, la confusión está en que a veces tienes una unidad que describe una clase, por ejemplo, dependiendo del libro que estés leyendo, y a veces define dos clases juntas que representan una idea. Pero luego, cuando aprendes sobre las pruebas de integración, te das cuenta de que esto es lo mismo. Básicamente, no, son dos piezas juntas en la integración. Y las pruebas se realizan en ambas. Uh, esto también se llama prueba de integración. Y a veces, nuevamente, dependiendo del libro que estés leyendo, se refiere a tu código en contra de un código externo que no posees. Así que esto es una prueba de integración. Hay mucha confusión. Y luego, debido a esta confusión, decidí no usar estos términos y en realidad profundizar. Y cuando profundicé, descubrí nuevas dimensiones de pruebas. Tenemos varias dimensiones de pruebas que podemos analizar. La primera son los límites, la segunda es el alcance de acción y la tercera es el tipo de sujeto, y en realidad descubrí más dimensiones de pruebas a lo largo de los años, pero hoy quiero hablar solo de estas dos primeras. Tengo otras conferencias y cursos y cosas así donde hablo sobre más dimensiones y cómo analizarlas. Pero para las dos estrategias de hoy, quiero hablar sobre estas dos dimensiones. Okay. Definámoslas. Límites. Los límites son fáciles. Solo significa aislado versus integrado. La mayoría de ustedes ya se refieren a unidades e integración, y en realidad se refieren a aislado o integrado. Y veremos, entonces aislado significa que solo probamos una cosa. Puede ser una clase, una función o lo que sea, pero es solo una cosa. Y el resto de las cosas que esta cosa importa, las simulamos. Okay.

8. Testing Dimensions and Efficiency

Short description:

Esta es una prueba aislada. En contraste, una prueba integrada es cuando probamos más de una cosa juntas. El alcance de acción significa una prueba de acción única o de múltiples acciones. Podemos tener múltiples combinaciones de estas dimensiones, pero elegir la combinación correcta es clave. Vamos a evaluar la eficacia de la prueba de acción única versus la prueba de múltiples acciones. En cuanto a la puntuación de confianza, las pruebas de múltiples acciones obtienen una puntuación más alta, pero en términos de eficiencia, son mucho menos efectivas que las pruebas de acción única debido a la maldición del influencer.

Esta es una prueba aislada. En contraste, una prueba integrada es cuando probamos más de una cosa juntas. Esta es una prueba integrada. A veces puede ser todo el conjunto, lo cual es una prueba de extremo a extremo. Así es la definición.

El alcance de acción significa una prueba de acción única o de múltiples acciones. ¿Y qué es eso? Digamos que tenemos una clase para métodos, ¿de acuerdo? Una prueba de acción única probará este método. Y una prueba de múltiples acciones probará varios métodos o funciones o cualquier otra cosa juntos en una prueba. Esta es una prueba de múltiples acciones y podemos tener varias combinaciones de las cosas como una prueba de acción única aislada o una prueba integrada de múltiples acciones o una prueba de acción única integrada. Sabes, podemos tener múltiples combinaciones de estas dimensiones, pero elegir la combinación correcta es clave aquí.

De acuerdo. Tienes. Combinaciones más efectivas para diferentes situaciones. De acuerdo. Colocamos suavemente a nuestro zarigüeya. No sé. Estoy sin palabras. De acuerdo. Sigamos adelante. De acuerdo. Así que evaluemos la eficacia de la prueba de acción única versus la prueba de múltiples acciones. En cuanto a la puntuación de confianza, las pruebas de múltiples acciones obtienen una puntuación más alta. Es una puntuación relativa. No es científica. Solo es relativa entre sí, porque cuanto más pruebas más cosas en una prueba, más confianza tienes de que tienes menos efectos secundarios. Pero en términos de eficiencia, las pruebas de múltiples acciones son mucho menos efectivas que las pruebas de acción única. ¿Por qué? Debido a la popularidad o lo que yo llamo la maldición del influencer. De acuerdo. Veamos.

9. Influencer Curse and Test Efficiency

Short description:

Cuando introduces más métodos o acciones a tus pruebas, aumentas la probabilidad de que varias pruebas fallen juntas. Esto se conoce como la maldición del influencer. Para mejorar la eficiencia de las pruebas, se recomienda preferir pruebas de acción única, aunque hay casos en los que las pruebas de múltiples acciones, como las pruebas de extremo a extremo, pueden ser apropiadas.

De acuerdo. Entonces digamos que tenemos esta clase aquí y tiene este método y digamos con varias pruebas para probar este método. De acuerdo. Ahora, si este método tiene un error, todas estas pruebas fallarán, pero ahora agreguemos otro método a la prueba. Entonces digamos que tenemos todas estas pruebas que prueban este método, pero también ejecutan este método también. Ahora, cada vez que esto tenga un error, todas las pruebas fallarán. Y cada vez que el segundo método tenga un error, todas las pruebas fallarán.

De acuerdo. Entonces, cuando introduces más métodos o más acciones a tus pruebas, estás aumentando la probabilidad de que muchas pruebas fallen juntas. Y eso es la maldición del influencer. Cuantos más seguidores tenga tu código, como más pruebas sigan tu código, menos eficientes son tus pruebas. De acuerdo. Entonces, la conclusión es preferir pruebas de acción única. De acuerdo. Hay momentos en los que quieres usar pruebas de múltiples acciones, como en las pruebas de extremo a extremo donde la cantidad de pruebas es menor y hablo de esto en mis cursos y otras conferencias, pero para la mayoría de las pruebas, quieres preferir pruebas de acción única.

10. Effectiveness of Isolated vs Integrated Testing

Short description:

Ahora hablemos sobre la efectividad de las pruebas aisladas versus las pruebas integradas. El contexto de tu aplicación y su tamaño son factores importantes a considerar. Las aplicaciones pequeñas, como microservicios o bibliotecas de código abierto, requieren enfoques de prueba diferentes a las aplicaciones medianas o grandes, como los monolitos. En términos de confianza, las pruebas integradas tienen una puntuación más alta, pero deben cubrir todo y no solo el camino feliz. Sin embargo, las pruebas integradas son mucho menos eficientes que las pruebas aisladas. Recomiendo ver la conferencia de J B Rinesberger sobre el engaño de las pruebas integradas para comprenderlo mejor.

De acuerdo. Ahora hablemos sobre la efectividad de las pruebas aisladas versus las pruebas integradas. De acuerdo. Veo muchas charlas sobre, no, escribir solo pruebas de integración y luego la pirámide de pruebas o escribir solo pruebas unitarias que son principalmente unidades o principalmente integración y todas esas cosas. Y seguí estas sugerencias durante un tiempo. Y me llevó a más confusión de mi parte, porque me di cuenta de que lo importante es el contexto de tu aplicación. Y parte de este contexto es el tamaño, el tamaño importa en las pruebas.

De acuerdo. Entonces, definamos el tamaño. Por un lado, tenemos las aplicaciones pequeñas, por ejemplo, pueden ser microservicios o micro-frontends o bibliotecas de código abierto o, ya sabes, pruebas de concepto, cosas así. Estas son aplicaciones más pequeñas. De acuerdo. Por otro lado, tenemos aplicaciones medianas a grandes, que la mayoría de las veces son monolitos. ¿De acuerdo? Si no los dividimos en micro-frontends, es un gran monolito con muchas partes móviles en comparación con un monorepo o algo así. Estas son aplicaciones grandes. De acuerdo. Estos son los términos.

De acuerdo. En términos de pruebas integradas versus aisladas, en la puntuación de confianza, tenemos una puntuación alta de confianza para las pruebas integradas y una puntuación baja de confianza para las pruebas aisladas porque perdemos contacto con la realidad cuando falsificamos cosas. Pero hay un asterisco en la parte integrada, porque significa que debemos cubrir todo en la parte integrada y no solo el camino feliz. Y la mayoría de las veces no es la situación. Por eso es una advertencia. Sabes, en un mundo ideal donde cubrimos todas las posibles rutas de código con pruebas integradas, sí, tenemos la máxima confianza, pero la mayoría de las veces no es el caso en la puntuación de eficiencia. Veremos pruebas integradas versus aisladas. Las pruebas integradas son mucho menos eficientes que las pruebas aisladas. Y hay muchas razones por las que eso es así. De acuerdo. Recomiendo ver una gran conferencia sobre el engaño de las pruebas integradas o que las pruebas integradas son un engaño, de J B Rinesberger, donde profundiza en eso. Y tengo otras conferencias donde profundizo en por qué esto es así.

11. Tipos de Pruebas Basadas en el Tamaño: Pruebas de Linterna y Pruebas de Láser

Short description:

Para aplicaciones pequeñas a medianas, una combinación de pruebas de acción única y pruebas integradas proporciona una solución más efectiva en las pruebas. Para aplicaciones grandes o de escala mediana a grande, una combinación de pruebas de acción única y pruebas aisladas mantiene un buen equilibrio entre confianza y eficiencia. Introducción de nuevos tipos de pruebas basados en el tamaño: pruebas de linterna para aplicaciones pequeñas y pruebas de láser para aplicaciones grandes.

De acuerdo. ¿Cuál es el problema de las pruebas integradas, pero son mucho menos eficientes que las pruebas aisladas. Y por esa razón, lo que me di cuenta es que para aplicaciones pequeñas a medianas, la solución más efectiva en las pruebas es usar una combinación de pruebas de acción única y pruebas integradas, porque de esa manera no perdemos la confianza y no perdemos tanta eficiencia porque no tenemos muchas pruebas en primer lugar, porque esta es una aplicación de tamaño pequeño, pero para aplicaciones grandes o de escala mediana a grande, la solución más efectiva en las pruebas o estrategia es usar una combinación de pruebas de acción única y pruebas aisladas, porque así preservamos un buen equilibrio entre la confianza y la eficiencia.

Simplemente voy a ignorar eso. De acuerdo. De acuerdo. Y como no quería seguir diciendo pruebas de acción única integradas o pruebas de acción única aisladas y cosas así, quiero encontrar mejores términos que encapsulen, como lo que quiero decir. Ahora quiero presentarles nuevos tipos de pruebas basados en el tamaño. Entonces, tipo número uno. De acuerdo. Para aplicaciones pequeñas, quiero algo que pueda cubrir todas las partes de la aplicación. Y luego pensé, ¿qué es una buena metáfora para, digamos que tengo todas estas partes en una habitación? Quiero iluminar todas juntas. Y luego pensé en, hey, puedo usar una linterna, una linterna, ya sabes, con el rayo de luz que puede alcanzar todas las partes juntas. De acuerdo. Y ahí es cuando pensé en el nombre de prueba de linterna, que son pruebas de corta distancia, de acuerdo. Piensen en una habitación pequeña, pruebas de acción única integradas, y estas son nuestras pruebas de linterna. Y este es el tipo número uno.

Ahora la otra nueva prueba en la que pensé fue para las aplicaciones grandes. Digamos que tengo un gran estadio con muchas partes distantes. De acuerdo. A veces quiero alcanzar esta parte o esta parte. ¿Qué puedo usar para alcanzarlo? No puedo usar una linterna porque el rayo de luz solo puede alcanzar una corta distancia. Necesito otro dispositivo. Y luego pensé, puedo usar un puntero láser y de esa manera puedo alcanzar otras partes más distantes y solo esas partes porque están aisladas. De acuerdo. Entonces es cuando pensé en el nombre de prueba de láser. De acuerdo. Que son de larga distancia, piensen en un gran estadio, pruebas de acción única aisladas. De acuerdo.

12. Recap: Pruebas de Linterna y Pruebas de Láser

Short description:

Tenemos pruebas de linterna para aplicaciones pequeñas y pruebas de láser para aplicaciones grandes. Cuando las pruebas superan las 500 líneas de código, considera cambiar a una estrategia de pruebas de láser. En resumen, aprendimos sobre el desarrollo de pruebas efectivas, diferentes dimensiones de pruebas y las estrategias de pruebas de láser y de linterna. Echa un vistazo al cuestionario y los recursos gratuitos para aprender más. Gracias por participar en mi primera charla TED. Disfruta del resto del evento.

Entonces, para recapitular, tenemos pruebas de linterna para aplicaciones pequeñas y pruebas de láser para aplicaciones grandes.

De acuerdo. Y podrías preguntarte, ¿cómo sabes cuándo cambiar entre estas dos estrategias? La regla general para mí es que cuando las pruebas superan las 500 líneas de código, probablemente mis pruebas integradas se vuelven menos eficientes. En ese momento, considero cambiar a una estrategia de pruebas de láser.

De acuerdo. Eso es todo por hoy. Resumamos lo que aprendimos. Aprendimos sobre el desarrollo de pruebas efectivas. Aprendimos sobre las diferentes dimensiones de testing que tenemos, y aprendimos sobre las estrategias de pruebas de láser y de linterna.

De acuerdo. Si quieres aprender más estrategias de pruebas efectivas, nuevamente, este es el cuestionario que preparé para ti. Este es el enlace. Este es el código QR, échale un vistazo. Y obtendrás más recursos gratuitos para aprender más sobre este tema, sobre el desarrollo de pruebas efectivas. Y con eso, quiero agradecerles a todos por participar en mi primera charla TED.

De acuerdo. Esta es mi primera, y muchas gracias. Estos son todos los detalles. Recuerda revisar el cuestionario y convertirte en un desarrollador de pruebas más efectivo.

De acuerdo. Disfruta del resto del evento. Adiós.

Hola Shai, ¿cómo estás? Estaba tan emocionado por la charla y di todo de mí, y perdí la voz. Así que podrás escuchar mi voz sexy en las preguntas y respuestas. Fue genial. Fue súper divertido. Me encantaron los videos en el medio. Así que teníamos la piscina antes. Veamos los resultados y en los resultados, en realidad no sabía la respuesta, así que mi, mi. Voto fue por las pruebas de hardware.

13. Resultados de la Encuesta y Métodos de Prueba

Short description:

Los resultados de la encuesta muestran un empate entre las pruebas de plomería y las pruebas de hardware. La respuesta correcta es una combinación de ambas. Las pruebas de plomería implican soplar humo a través de tuberías para verificar si hay fugas, mientras que las pruebas de hardware implican enchufar un dispositivo y asegurarse de que no explote. Las pruebas de plomería se realizaron primero, seguidas de las pruebas de hardware.

Y después estuve leyendo al respecto. Entonces, ¿cuál es tu conclusión en cuanto a los resultados de la encuesta? Veo los resultados ahora y parece que hay un empate entre las pruebas de plomería y las pruebas de hardware, y la respuesta correcta es una combinación de ambas. Nadie eligió la opción de pruebas manuales, es como un 0% o algo así, pero en realidad, cuando sabes, siempre pensé que se trataba de las pruebas de plomería y luego, porque, ya sabes, soplan humo a través de las tuberías para ver si no hay fugas, pero en realidad también proviene de las pruebas de hardware. De acuerdo. Entonces, las pruebas de hardware, la prueba consistía en enchufarlo y si no explotaba en humo, funcionaba como una prueba de humo. Así que en realidad es una combinación de ambas. Por lo tanto, las respuestas A y B son correctas. Exactamente. Sí. Eso es lo que investigué después. Y las pruebas de plomería se realizaron primero y luego las pruebas de hardware. Así que eso es genial.

QnA

Q&A sobre camisetas y estrategia de pruebas

Short description:

Tenemos algunas preguntas sobre este tema, así que te las leeré. La primera es sobre conseguir una camiseta con los derechos de prueba, duerme tranquilo. Estoy planeando una línea completa de camisetas divertidas relacionadas con las pruebas. Otra pregunta es sobre el tamaño de la aplicación y su impacto en la elección de una estrategia de pruebas. Enfatizo la importancia de considerar el tamaño de la aplicación y si la estrategia elegida es realmente rentable. Para aplicaciones más pequeñas, se recomienda una combinación de pruebas de acción única e integradas, mientras que para aplicaciones más grandes, las pruebas aisladas son más adecuadas.

Tenemos algunas preguntas sobre este tema, así que te las leeré. Y la primera es de S y la camiseta en las preguntas es, ¿podemos conseguir una camiseta con los derechos de prueba, duerme tranquilo? En realidad, tengo planes. Muchas gracias. Sí, también quiero tener una. Lo haré. Sí, lo haré. Estoy planeando, tengo un design y planeo lanzarlo, solo necesito encontrar el tiempo para ver dónde puedo producirlo a nivel internacional y cosas así. Pero si quieres estar en la lista, contáctame en shai.hi-res.io y te agregaré a la lista de notificaciones cuando esté disponible. Pero sí, estoy planeando una línea completa de camisetas divertidas relacionadas con las pruebas. Has creado tus propios términos, así que puedes tener muchas camisetas diferentes con diferentes frases. Genial. Sí, pruebas láser y cosas así, humo y láseres y cosas así.

Así que tenemos otra pregunta aquí, que es, ¿importa el tamaño de la aplicación al elegir una estrategia de prueba? Uh, creo que lo respondí en la charla. Al final. Pero sí, sí. Este es el punto principal que intenté hacer, cuando leemos sobre las publicaciones de blogs que sugieren una estrategia específica, solíamos leerlo desde nuestra perspectiva. Y podríamos elegir la estrategia incorrecta para nuestra aplicación. Si no aplicamos, o espera un segundo, creo que, ¿cuál es el tamaño? ¿Cuál es el tamaño de mi aplicación? Y sí, ¿esta estrategia, esta técnica realmente es la más rentable técnica? Y por eso dije que si lo juzgas todo, eso es lo que intenté hacer. Si juzgas todo y tienes más, más aspectos y más dimensiones para juzgar. Como dije, tienes un tema y tienes todas estas cosas que debes considerar. Eso es lo que intenté hacer en mi laboratorio aquí en mi oficina, por cierto, esta es mi familia. Entonces, lo que intentaron hacer es descubrir cuál es el par de contexto más rentable. Entonces, para el contexto de aplicaciones más pequeñas, intenta usar una combinación de pruebas de acción única, de todos modos para tus pruebas micro. Y haz la prueba de linterna, que es la prueba de acción única e integrada. Así es como obtendrás más beneficios, más eficiencia y más confianza. Pero para aplicaciones más grandes, en las que la mayoría de nosotros trabajamos en empresas donde todavía tenemos un monolito y aplicaciones grandes, es bastante difícil escribir pruebas integradas en un entorno así de manera muy repetitiva o convencional, donde todos conocen los límites, el camino correcto. Donde las pruebas serán muy deterministas, ¿verdad? Exactamente. Por eso recomiendo, está bien, adhiérete a las pruebas aisladas para esa estrategia y usa las pruebas integradas para cosas como pruebas de humo de las que hablo en otras conferencias. Oh, tenemos una pregunta levantada.

Choosing Cost-Effective Testing Strategies

Short description:

En las pruebas, es importante elegir estrategias que sean rentables para nuestras necesidades y contexto específicos. No hay un enfoque único que funcione para todos, y debemos evaluar nuestra situación en función de los principios fundamentales. Comprender las dimensiones de nuestro proyecto, como el tamaño y los requisitos de la aplicación, nos ayuda a determinar el enfoque de prueba más adecuado. Si bien la sabiduría común puede sugerir ciertas prácticas, debemos priorizar lo que funciona en situaciones reales. Además, a medida que los proyectos evolucionan y se vuelven más complejos, es posible que nuestra estrategia de prueba deba adaptarse en consecuencia.

hand-teasing, que es increíble. Gracias. Ganaste la camiseta gratis. Sí. Me gusta que hayas mencionado, y no solo tú, muchos de los oradores aquí en la conferencia mencionaron que debemos elegir las pruebas adecuadas que sean más rentables para nuestras necesidades, para nuestro contexto, y creo que eso tiene más sentido. No hay una estrategia única que funcione para todos. Debemos entender exactamente dónde estamos y dónde queremos estar. Sí. Y eso es algo de lo que creo que deberíamos hablar en el mundo de las pruebas, más bien intentar ir a los principios fundamentales y tratar de evaluar las cosas, no por los términos que estamos acostumbrados a usar, sino por lo que es más correcto para mi situación. Y definamos cuál es mi situación. ¿Estoy trabajando en una aplicación pequeña, en una aplicación grande? Y luego, bueno, ¿cuáles son las diferentes dimensiones? ¿Qué necesito realmente aquí? ¿Realmente, como en Angular, por ejemplo, en React es bastante obvio escribir componentes o pruebas para el DOM. Es más como es más fácil, es más rápido. En Angular, en realidad es más rápido escribir solo una prueba para las clases y no para el DOM, y nuevamente, dejar las pruebas del DOM para los componentes reutilizables. Pero eso no es lo común que se dice. Lo común que leerás, pero personalmente no me importa lo común, me importa lo que funciona en situaciones reales. Por eso necesitamos más pensamiento crítico en estos términos. Solo un pensamiento final que también tengo es que el mismo proyecto podría comenzar con una estrategia y cuando evolucione, tendrá que cambiar su estrategia porque la aplicación crece y se vuelve más compleja, así que debemos tener eso en cuenta sin duda. Fue una gran charla, Chi. Realmente lo aprecié. Muchas gracias por eso. Gracias a ti también. Gracias por tenerme.

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.
TestJS Summit 2023TestJS Summit 2023
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.