Desarrollo Efectivo de Pruebas

¡Hola a todos y bienvenidos a la charla de introducción al Desarrollo Efectivo de Pruebas! Soy Shai Reznick y hoy voy a enseñarles una nueva forma de pensar sobre las pruebas que cambiará su vida de testing para siempre y aumentará su productivity. Así que comencemos.

Como dije, soy Shai Reznick. Soy conocido como el chico de las Pruebas Efectivas y a veces también como el chico de las Angular Testing. También soy un Experto Desarrollador de Google y fundé HiRise.IO, que es una empresa de educación y formación que enseña a los desarrolladores a 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í.

Bueno. Así que mi principal objetivo en la vida es ayudar a las empresas ocupadas a ser más rentables a través de la transformación de las testing. Eso significa que tomamos su empresa ocupada con su horario, sin parar en el desarrollo, y encontramos una forma de integrar las testing en su día a día. Si están interesados en eso, háganmelo saber. Bueno, podríamos llevar a sus desarrolladores de dormir así a dormir así, donde como me gusta decir, prueba bien, duerme bien. Bueno. Y no se trata solo de dormir bien por la noche, también se trata de ser más profesional. Así que podrían hacer los cambios en su code o aplicar esta nueva técnica que aprenden sin el miedo de introducir nuevos errores en producción. Y si quieren descubrir sus mayores errores de testing, preparé un cuestionario, algunas preguntas que pueden responder, y les mostraré cuáles son sus errores y cómo solucionarlos y compartiré con ustedes algunos recursos gratuitos nuevos sobre las testing. Así que echen un vistazo en este enlace o en este código QR, los llevará al mismo enlace y llegarán a ese cuestionario.

Vale. Ahora un descargo de responsabilidad. Así que soy conocido, si buscas mi nombre en YouTube, podrías encontrar charlas locas mías, como, ya sabes, a veces es una obra de teatro y a veces es un juego show 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 la mente y comparto con la audiencia cuál es mi proceso de pensamiento y todas las travesuras que pasan por mi cabeza mientras estoy probando 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 que, ya sabes, la gente está interrumpiendo las transmisiones de otras personas, así que podrías ver interferencias o podrías ver lo que otros vecinos míos aquí están viendo. Así que lo siento por eso. Pido disculpas por adelantado por cualquier cosa que puedas ver. ¿Vale? No quería, por eso no quería crear una charla loca hoy porque no sé cuándo ocurrirán estas interrupciones de transmisión. Así que simplemente me estoy ceñiendo a la charla educativa a la antigua usanza y eso es todo. Así que este es el descargo de responsabilidad. Lo siento por eso. Y esperemos, esperemos que tengamos un proceso sin problemas. Vale, genial. Así que ahora comencemos.

Vale. Así que en 2009, era un desarrollador en mi trabajo diario y tenía un proyecto secundario por la noche. Así que trabajaba de nueve a cinco en el trabajo diario y hasta las 2 a.m. En la startup. Y así eran mis días. Y estaba en esto, lo que llamo el círculo del destino porque me apresuraba y trataba de cumplir con todos los plazos y avanzando rápidamente, produje una pobre calidad de code que produjo errores inesperados, que a su vez produjeron más pobre calidad de code debido al miedo a los errores inesperados. Me asusté mucho, vale. Y, y no quería cambiar y mejorar el code y eso llevó a la frustración y a intentar destruir el ordenador o no sé, y eso llevó incluso a un lugar más aterrador donde tenía la sensación de estar en arenas movedizas donde cada vez que arreglaba los errores, introducía cuatro errores más en, en la aplicación. Y, sentía como si me estuviera hundiendo más y más en las arenas movedizas. Y empecé a tener este mareo y, y, uh, no podía respirar y estos ataques y no sabía qué me pasaba, así que fui, en realidad fui al hospital y me hicieron pruebas cuando se volvió más grave. Y en realidad me dijeron que no tenía nada malo físicamente. Y sugirieron que podría tener ataques de pánico y los tuve. Esto es lo que tuve ataques de pánico por no cumplir con el plazo. Y, ya sabes, me perdí los plazos y tengo más errores que arreglar y no sé, tengo esta incertidumbre sobre cuándo aparecerán más errores y, fue verdaderamente un lugar aterrador en mi vida.

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

Así que empecé a aprender sobre testing y me encontré con términos extraños, como unit e integration, y luego end to end, y no sabía qué elegir cuándo. Y uh, lo siento, como te dije. Um, está bien, olvidémonos de lo que acabamos de ver. Está bien. Así que tenía todos estos términos como unit integration y no sabía qué, ya sabes, qué elegir y cómo escribirlos. Y en algún lugar leí que las unit tests son para los desarrolladores y la integración y end to end son para QA. Así que decidí empezar con las unit tests. Uh, entonces al principio, fue muy difícil entender qué, ¿qué estoy haciendo? Pero después de un tiempo me volví mejor y mejor. Y pensé para mí mismo, está bien, lo tengo. Pero entonces, ya sabes, empecé a tener errores como 100% de cobertura o 90% de cobertura, pero aún así tenía errores en producción. Y entonces me di cuenta de que las unit tests no son suficientes. También necesito pruebas de integración.

Así que lo intenté, realmente, realmente lo intenté. Así que intenté escribir pruebas de integración y al principio de nuevo, fue muy difícil, pero al final, seguía siendo difícil porque las pruebas de integración son súper difíciles. Parecía fácil al principio, pero cuando te das cuenta de que tienes tanta lógica y piezas móviles en tu code y todo esto, como, complejidad ciclomática y otros términos que te hacen sonar más inteligente de lo que eres, pero básicamente diciendo que tienes muchas rutas de code en tu aplicación, ya sabes, puntos de decisión y cosas así, eso hizo que las pruebas de integración fueran mucho más difíciles y más lentas de ejecutar y eso me llevó a escribir solo pruebas para el camino feliz cuando las cosas son exitosas y no para comprobar situaciones de error, cosas así. Y eso me llevó a tener menos confianza en mis pruebas de integración porque me di cuenta de que es solo una ilusión. No me dan realmente plena confianza en mi code. Y siempre sentí que esta manta es demasiado corta, ya sabes, cada vez que intento usar una nueva técnica, ya sabes, integración o unit o algo así, siempre sufro por algo más. Así que después de unos años de testing, me convertí en consultor de testing y ayudé a las empresas con su code. Y les enseñé las mismas formas tradicionales de como la pirámide de testing y todas esas cosas. Y empecé a frustrarme porque no tenía los resultados que quería tener. Y este soy yo frustrado. Está bien. Llegué a la conclusión de que ya había tenido suficiente. ¿Está bien? Necesitamos un nuevo enfoque. Necesitamos una mejor manera de hacer las cosas.

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

Y si pensamos en las estrategias, herramientas y técnicas que estamos acostumbrados a aplicar o usar en nuestras pruebas, vale. Ahora, cuando piensas en la confianza y la eficiencia y los juzgas por estos términos, podemos ver que algunas estrategias conducen a más eficiencia, pero menos confianza y algunas conducen a más confianza y menos eficiencia, por ejemplo, la prueba de extremo a extremo, donde tienes mucha confianza porque todas las partes móviles están integradas juntas y pruebas todo en un solo lugar, pero son las pruebas menos eficientes de todas porque son las más lentas y requieren más code y fallan más a menudo y cosas así.

Entonces, aunque nunca puedes alcanzar un punto perfecto al 100%, siempre sufres de bugs. El punto es encontrar un equilibrio. Equilibrio en la confianza y eficiencia que tenemos de un término de estrategia específico 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, rentable, rentable. Tal vez puedo llamarlo tarea efectiva. Y ahí fue cuando se me ocurrió el desarrollo efectivo de pruebas. Y la idea aquí es encontrar mejores términos, mejores estrategias y mejores herramientas para escribir tareas más rentables. Así que hay muchos temas que cubrir. Desarrollamos pruebas efectivas, pero hoy, porque solo tenemos tiempo limitado, solo nos vamos a centrar en dos estrategias.

De acuerdo. De nuevo, lo siento. No sé qué están haciendo mis vecinos. Nos centraremos en dos estrategias. 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 vas a 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 como un maníaco con una motosierra que solo sabe cómo usar esta herramienta.

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

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

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 se importan entre sí, esta es nuestra aplicación. Vale. Y cuando piensas en unit testing, la confusión ahí es que a veces tienes una unidad que describe una clase, por ejemplo, dependiendo de qué libro estás leyendo, y a veces define como dos clases juntas que representan una idea. Pero luego cuando aprendes sobre las pruebas de integración, aprendes que esto, es lo mismo. Básicamente, no, son dos piezas juntas en integración. Y las pruebas ambas. Eh, esto también se llama una prueba de integración. Y a veces de nuevo, dependiendo de qué libro estás leyendo, se refiere a tu code contra code externo que no posees. Así que esto es una prueba de integración. Así que hay mucha confusión. Y entonces, debido a esta confusión, decidí no usar estos términos y en realidad profundizar más. Y cuando profundicé, descubrí nuevas dimensiones de testing. Tenemos varias dimensiones de testing que podemos analizar. La primera es los límites, la segunda es el alcance de la acción, y la tercera es el tipo de sujeto, y en realidad tenemos más dimensiones de testing que descubrí 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 de estas dos dimensiones. Vale. 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, así que aislado significa que solo probamos una cosa. Podría ser una clase, una función o lo que sea, pero es solo una cosa. Y el resto de las cosas que esto importa, falsificamos. Vale.

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 podría ser la cosa completa, que es una prueba de extremo a extremo. Así que esta es la definición.

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

Vale. Tienes. Combinaciones más efectivas para diferentes situaciones. Vale. Suavemente colocamos nuestro zarigüeya. No sé. Eso. Estoy sin palabras. Vale. Vamos a continuar. Vale. Así que vamos a juzgar la efectividad de la prueba de acción única versus la prueba de acción múltiple. En la puntuación de confianza, las pruebas de acción múltiple obtienen una puntuación más alta. Es una puntuación relativa. No es científico. Solo es relativo entre sí, porque cuanto más pruebas haces en una prueba, obtienes más confianza de que tienes menos efectos secundarios. Pero en términos de eficiencia, las pruebas de acción múltiple son mucho menos efectivas que la prueba de acción única. ¿Por qué? Debido a la popularidad o lo que llamo la maldición del influencer. Vale. Veamos.

Vale. Entonces digamos que tenemos esta clase aquí y tiene este método y digamos con varias pruebas para probar este método. Vale. Ahora, si este método tiene un error, ahora 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 esto tenga un error el segundo método, todas las pruebas fallarán.

Vale. Entonces, cuando introduces más métodos o más acciones a tus pruebas, estás aumentando la probabilidad de fallar en muchas pruebas juntas. Y eso es la maldición del influencer. Cuantos más seguidores tenga tu code, como más pruebas que siguen tu code, menos eficientes serán tus pruebas. Vale. Entonces la conclusión es preferir las pruebas de acción única. Vale. Hay algunas veces que quieres usar pruebas de acción múltiple y como en las pruebas de extremo a extremo donde la cantidad de pruebas son menores y hablo de estas en mis cursos y otras masterclass, pero para la mayoría de las pruebas, quieres preferir pruebas de acción única.

Vale. Ahora hablemos sobre la efectividad de las pruebas aisladas versus las integradas. Vale. Veo muchas charlas sobre, no, escribir solo pruebas de integración y luego la pirámide de testing o escribir solo unit tests son en su mayoría unidades o en su mayoría integración y todas esas cosas. Y seguí estas suggestions durante un tiempo. Y me llevó a más confusión por 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 testing.

Vale. Entonces definamos tamaño. En un extremo, tenemos las aplicaciones pequeñas, un ejemplo de estas pueden ser los microservices o micro-frontends o bibliotecas de código abierto o, ya sabes, pruebas de concepto, cosas así. Estas son aplicaciones más pequeñas. Vale. En el otro extremo, tenemos aplicaciones medianas a grandes, que la mayoría de las veces los ejemplos de estas son monolitos. ¿Vale? 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í. Entonces estas son aplicaciones grandes. Vale. Estos son los términos.

Vale. En términos de integrado versus aislado en la puntuación de confianza, tenemos una alta puntuación de confianza para la prueba integrada y una puntuación de confianza más baja para la aislada porque perdemos contacto con la realidad cuando falsificamos cosas. Pero hay un asterisco en la parte integrada, porque significa que debemos cubrir todo en lo integrado y no solo el camino feliz. Y la mayoría de las veces no es la situación. Por eso es una advertencia. Vale. Ya sabes, en un mundo ideal donde cubrimos todos los posibles caminos de code con pruebas integradas, sí, tenemos la máxima confianza, pero eso la mayoría de las veces no es el caso en la puntuación de eficiencia. Veremos integrado versus aislado. Integrado es mucho menos eficiente que la prueba aislada. Y hay muchas razones por las que es así. Vale. Sugiero ver una gran conferencia sobre la estafa de las pruebas integradas o las pruebas integradas son una estafa por J B Rinesberger, donde cubre eso en profundidad. Y tengo otras masterclass donde profundizo en por qué este es el caso.

Vale. ¿Cuál es la estafa de las pruebas integradas, pero son mucho menos eficientes que las pruebas aisladas. Y por esa razón, lo que llegué a darme cuenta es que para aplicaciones pequeñas a medianas, la solución más efectiva en pruebas es utilizar una combinación entre pruebas de acción única e 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 grandes monolitos o aplicaciones de escala mediana a grande, la solución más efectiva en pruebas allí o la estrategia allí es utilizar una combinación de pruebas de acción única y aisladas porque de esa manera preservamos un buen equilibrio entre la confianza y eficiencia.

Voy a ignorar eso. Vale. Vale. Y porque no quería seguir diciendo como prueba de acción única integrada o pruebas de acción única aisladas y cosas así, quería encontrar mejores términos que encapsulen, como lo que quiero decir. Quiero presentarles ahora nuevos tipos de pruebas basadas en tamaño. Entonces tipo número uno. Vale. Para aplicaciones pequeñas, quiero algo que pueda cubrir todas las partes de la aplicación. Y entonces pensé, vale, ¿cuál es una buena metáfora para, digamos que tenía todas estas partes en una habitación. Quiero arrojar luz sobre todas estas juntas. Y entonces pensé en, oye, puedo usar una linterna, ya sabes, con el rayo de luz puede golpear todas las partes juntas. Vale. Y fue entonces cuando pensé en el nombre de prueba de linterna, que son de corta distancia, vale. Piensa en la pequeña habitación con prueba de acción única integrada, y estas son nuestras pruebas de linterna. Y este es el tipo número uno.

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

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

Vale. Y podrías preguntarte, ¿cómo sabes cuándo cambiar entre dos estrategias? La regla general para mí es cuando las pruebas superan las 500 líneas de code, entonces sé que probablemente mis pruebas integradas se están volviendo menos eficientes. Y entonces considero cambiar a una estrategia de prueba de láser.

Vale. Eso es todo por hoy. Resumamos lo que hemos aprendido. Aprendimos sobre el desarrollo efectivo de pruebas. Aprendimos sobre las diferentes testing dimensiones que tenemos, y aprendimos sobre las estrategias de prueba de láser y linterna.

Vale. Si quieres aprender más sobre estrategias de pruebas efectivas, de nuevo, este es el cuestionario que preparé para ti. Este es el enlace. Este es el QR code, échale un vistazo. Y obtendrás más recursos gratuitos para aprender más sobre este tema, sobre el desarrollo efectivo de pruebas. Y con eso, quería agradecerles a todos por participar en mi primera charla TED.

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

Vale. Disfruta el resto del evento. Adiós.

Hola Shai, ¿cómo estás? Estaba tan emocionado por la charla que di todo y perdí mi voz. Así que puedes escuchar, mi voz sexy en la Q&A. Fue genial. Fue súper divertido. Me encantaron los videos en medio. Así que tuvimos la encuesta antes. Así que echemos un vistazo a los resultados y en los resultados, en realidad no sabía la respuesta, así que mi, mi. Voto fue en el hardware testing.

Y después estuve leyendo sobre ello. Entonces, ¿cuál es tu conclusión con respecto a los resultados de la encuesta? Así que estoy viendo los resultados ahora y parece que tenemos un empate entre fontanería y hardware testing y la verdadera respuesta es hand-teasing nadie eligió hand-teasing es como 0% o algo así, pero no, en realidad, cuando tú, tú sabes, siempre pensé que era, en relación a la fontanería y luego porque, tú sabes, soplan humo a través de las tuberías para ver si no tienes ninguna, como, tú sabes, fugas pero en realidad también viene del hardware testing. Vale. Entonces, las pruebas de hardware, la prueba era, si lo conectas y no explota en humo, funciona como presionas la prueba de humo. Así que en realidad es una combinación entre. Así que la respuesta correcta es que tanto la A como la B son correctas. Exactamente. Sí. Eso es lo que, lo que investigué después. Y la de fontanería fue la primera, llegó primero y luego las pruebas de hardware. Así que eso es genial.

Tenemos algunas preguntas en este tribunal, así que te las leeré. Y la primera es de la S y la camiseta en las preguntas son, ¿podemos conseguir una camiseta con los derechos de prueba, duerme tranquilo? De hecho, tengo un plan. Muchas gracias. Sí, yo también quiero tener una. Lo haré. Sí, lo haré. Estoy jugando con el, tengo un design y estoy planeando emitir como, solo necesitaba encontrar el tiempo para ver dónde puedo producirlo internacionalmente y cosas así. Pero si te gustaría estar en la lista, contáctame en shai.hi-res.io y te pondré en la lista de notificaciones cuando se lance. Pero sí, estoy planeando una línea completa de camisetas divertidas relacionadas con las testing. Has creado tus propios términos, así que puedes tener muchas camisetas diferentes con diferentes dichos. Genial. Sí, pruebas láser y cosas así, humo y láseres y cosas así.

Entonces, tenemos otra pregunta aquí, que es, ¿importa el tamaño de la aplicación al elegir la prueba, una estrategia de testing? Uh, yo, yo, como, creo que es, respondí en la, en la charla. Al final. Pero sí, entonces, sí. Este, este es el, el, el, el punto que intenté hacer fue que cuando leemos sobre las publicaciones de blog que sugieren una estrategia específica, sabes, nosotros solíamos leerlo desde, bien, nuestro punto de vista. Y podríamos tomar la estrategia equivocada para nuestra aplicación. Si no aplicamos el, o esperamos un segundo, creo, ¿cuál es el tamaño? ¿Cuál es el tamaño de mi aplicación? Y sí, ¿esta estrategia, como, es esta técnica realmente 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, como tienes un sujeto y tienes todas estas cosas que necesitas considerar. Eso es lo que intenté hacer en mi laboratorio aquí en mi oficina, por cierto, esta es mi familia. Así que lo que intentaron hacer es averiguar cuál es el par más rentable por contexto. Así que para el contexto de aplicaciones más pequeñas es tratar de usar una combinación de acción única, acciones únicas de todos modos para tu micro prueba. Y hacer la prueba de la linterna, que es la prueba de acción única e integrada. Así es como obtendrás las mayores ganancias y la mayor eficiencia y confianza. Pero para las aplicaciones grandes, que la mayoría de nosotros trabajamos en empresas donde todavía tenemos monolitos y grandes monstruos de aplicaciones, es bastante difícil escribir pruebas integradas en un entorno así de una manera muy repetitiva o convencional donde todos conocen las fronteras, el camino correcto. ¿Dónde las pruebas serán muy deterministas, verdad? Exactamente. Por eso recomiendo, está bien, apegarse a las pruebas aisladas para esa estrategia y usar las pruebas integradas para cosas como pruebas de humo de las que hablo en otras conferencias. Oh, tenemos un hand-teasing. Alguien respondió