Pruebas que te ayudan a encontrar defectos más rápido

¡Hola y bienvenidos a mi charla, pruebas que te ayudan a encontrar defectos más rápido! Mi nombre es Philip, pero todos me llaman Phil. Así que tú también puedes hacerlo. Vivo en una ciudad llamada Potsdam en Alemania, justo al lado de Berlín. Pero aparte de los hipsters, también tenemos castillos. También soy CTO de una empresa llamada Oution y he ocupado roles de liderazgo técnico en los últimos años. He sido mentor de varios desarrolladores menos experimentados en el camino.

Y al hacerlo, he aprendido sobre los diferentes errores que cometen las personas y los problemas en los que se meten al escribir pruebas de software. Como disfruto mucho escribir pruebas, soy un gran fanático de TDD, porque me ayuda a organizarme y trabajar en pequeños pasos. Pensé que esta sería una buena oportunidad para compartir algunos de esos conocimientos. Obviamente, yo mismo he cometido la mayoría de esos errores en los últimos años, lo suficiente como para analizarlos y ver qué es realmente importante y qué no lo es. Lo cual me lleva también a mi primer punto. Me gustaría comenzar esta charla no con un tema, sino con los temas que no se tratarán en esta charla. Y lo primero será la nomenclatura de las pruebas, ¿verdad? Hay varios estilos diferentes para escribir nombres de pruebas y descripciones de pruebas. Solo para darte un ejemplo, voy a ejecutar algunos aquí para que veas cómo se ven en un ejecutor de pruebas. Por ejemplo, hay un estilo llamado Rspec, donde básicamente lees todos los describe hasta el it, y luego esto forma una oración completa. Por ejemplo, aquí se puede identificar a un usuario. Esta es una forma de hacerlo, obviamente, ¿verdad? También hay un estilo diferente, BDD, Desarrollo Guiado por el Comportamiento, donde se usa mucho la palabra clave should, así que aquí he usado usuario simplemente como un nombre para un grupo. Y luego el nombre de la prueba debería ser posible identificar a un usuario. Ahora, el punto importante aquí es que ambos son igualmente buenos, ¿verdad? No hay uno mejor que el otro. Es solo una cuestión de gusto personal, lo que te gusta más, lo que funciona para ti. Por eso no quiero hacer un problema de esto aquí. En esta charla voy a usar mucho el estilo BDD, should, pero no creo que sea mejor si prefieres escribir tus pruebas de manera diferente. Eso está perfectamente bien, así que eso no es realmente de lo que trata esta charla.

Lo segundo de lo que trata esta charla no es sobre ciertas reglas arbitrarias cuando se trata de cuántas afirmaciones deberían haber en un caso de prueba, ¿verdad? Hay reglas vinculadas que dicen que cada prueba solo debe tener una afirmación y no creo que siempre sea, ya sabes, correcto. Por ejemplo, estos dos son exactamente iguales. El primero usa una afirmación donde, ya sabes, queremos afirmar que un objeto de usuario tiene cierta estructura, por lo que podemos usar el objeto de coincidencia para comparar todas esas propiedades. Y si algo falta, entonces falla, pero podríamos escribir la misma prueba exacta también con dos afirmaciones donde verificamos las propiedades individualmente. Probablemente haya pros y contras en cualquiera de estos enfoques, pero no diría, ya sabes, que uno es particularmente mejor o uno es peor. Así que también aquí, ya sabes, esto no es algo de lo que me gustaría hablar. Encuentra algo que funcione para ti y sigue con eso, ¿verdad? Y obviamente... entonces de lo que tampoco trata esta charla es de, espero, de buscarle problemas a mi ejemplo. He elegido ejemplos deliberadamente simples para, ya sabes, transmitir la idea general. Obviamente no son del mundo real, ¿verdad? Probablemente no los encontrarías exactamente así en un escenario del mundo real, a veces incluso pueden contradecir ciertas reglas que menciono, pero siempre es para, ya sabes, transmitir mejor el punto del que estoy hablando.

De acuerdo, con el terreno nivelado, vamos directo al grano y he estructurado esta charla en dos partes separadas. La primera parte se centra en la estructura general de las pruebas, como organizar todo. Y luego la segunda parte es, ya sabes, cómo realmente escribir pruebas y, ya sabes, dos trampas comunes en las que la gente cae.

Entonces, comencemos con lo primero que veo que sucede mucho y también déjame señalar mi ejecutor de pruebas. Estoy en eso. Y esto es mientras no creo que deba haber solo una afirmación, solo una afirmación en una prueba, lo que sí creo es que cada prueba debe cubrir exactamente un caso de uso. Este es un error que puedes cometer muy fácilmente.

Por ejemplo, aquí, la descripción de la prueba y realmente solo enfócate en la descripción de la prueba aquí, debería ser posible leer desde y escribir en la base de datos. Ahora, y vemos que esta prueba falla. Si te preguntara, ya sabes, ¿qué es? ¿Es la parte de lectura o la parte de escritura? Probablemente no podrías decirlo de memoria, ¿verdad? Y también, si estás trabajando, ya sabes, en tu software y esta prueba, ya sabes, comienza a fallar nuevamente, también necesitas averiguar, ya sabes, qué parte es la que acabas de romper, ¿verdad?

Mi regla general aquí es que siempre que escribas las palabras `y` y `o` en la descripción de una prueba, simplemente haz dos pruebas, ¿verdad? Ya estás combinando demasiado en ese momento, lo cual, ya sabes, no debería combinarse. Entonces, ¿qué podemos hacer al respecto? Ya sabes, podemos dividirlo y déjame, ya sabes, volver a señalar mi ejecutor de pruebas nuevamente. Ahora tenemos dos pruebas. Una debería ser posible leer desde la base de datos. La otra es que debería ser posible escribir en la base de datos. Ahora, si la segunda falla, sabemos, está definitivamente relacionada con la parte de escritura. Eso está roto. No es la parte de lectura. Eso es bueno porque, ya sabes, desde el fallo de la prueba, podemos ver qué está sucediendo.

Sin embargo, queda una pequeña mejora por hacer aquí. ¿Qué sucede, por ejemplo, si ambas fallan? Porque aquí podemos ver que los casos de uso no necesariamente solo se limitan a la palabra clave `y` como la única cosa a tener en cuenta. Si lo piensas, ¿qué necesitan tanto la lectura como la escritura en la base de datos? Entonces, si ambas fallan, podría ser que haya problemas separados. Podría ser simplemente que la conexión no está funcionando. Esta sería la última mejora que haría, agregar una tercera prueba que solo busque la conexión. Entonces, ya sabes, si la prueba de conexión falla, y la de lectura y escritura también, está definitivamente relacionado con la conexión. Definitivamente hay un problema allí, y es muy probable que esto también afecte los aspectos de lectura y escritura, mientras que esto no está tan claro si no tienes esa especificación.

Y algunos de ustedes ahora podrían estar pensando, ya sabes, si haces TDD, esto es algo que, ya sabes, esta estructura viene de manera natural, porque si comienzas a construir esta interfaz, definitivamente comenzarías asegurándote de que haya una conexión a la base de datos. Esta sería la primera prueba que escribirías, y luego agregarías otras pruebas después de ese hecho. Sin embargo, incluso si haces TDD, a veces te dejas llevar, ya sabes, si quieres lograr algo, y es entonces cuando comienzas a agrupar múltiples casos de uso en una sola prueba, esto te afectará más adelante. La segunda cosa de la que me gustaría hablar en cuanto a la estructura general de las pruebas es el uso de afirmaciones, ¿verdad? Y la trampa en la que puedes caer aquí es que esencialmente podemos expresar todo como una expresión booleana, como hacer una verificación verdadera o falsa, ¿verdad? He comenzado aquí, déjame omitir esa segunda prueba por ahora. He comenzado aquí verificando si una cierta propiedad de un usuario tiene el nombre correcto.

Permíteme, ya sabes, señalar mi ejecutor de pruebas para que podamos ver que falle. Ahora, si, ya sabes, esa prueba está bien, ¿verdad? Verifica lo correcto, ¿verdad? Simplemente lo hace de una manera que si falla, no nos dice realmente qué está sucediendo, ¿verdad? Ahora puedes ver que la prueba simplemente nos dice que esperaba verdadero, pero recibió falso. Entonces, ¿qué significa eso? ¿Verdad? Esto nos obliga a abrir el editor y navegar hasta el archivo de prueba para, ya sabes, averiguar qué está sucediendo aquí. Sin embargo, podemos, ya sabes, hacerlo mejor. Podemos, por ejemplo, utilizar la afirmación para tener una propiedad, decir la cosa y hacer que nuestra prueba se vea así. Ahora esperamos que un objeto de usuario tenga una propiedad llamada John, ¿verdad? Y ahora el mensaje de error se ve, ya sabes, ligeramente diferente, ¿verdad? En primer lugar, nos dice que está buscando una cierta ruta aquí llamada nombre. Luego nos dice que esperaba un valor llamado John, pero obtuvo Jane, ¿verdad? Y esto nos brinda contexto, ¿verdad? Entonces, esto no solo nos dice que la prueba, que esperemos tenga un nombre agradable, falla, sino que también nos brinda algo de contexto sobre por qué falló, ¿verdad? Y esto, a su vez, ya sabes, te ayuda a comprender más rápido, ya sabes, qué hiciste recientemente, cómo se relaciona tal vez con este error para que puedas averiguar qué podría, ya sabes, estar causando esto, ya sabes, ¿qué cambiaste que causa este error? Otra cosa común que podemos hacer es, por ejemplo, probar errores, ¿verdad? A veces lanzas excepciones y quieres asegurarte de que se lancen las excepciones correctas, no puedes hacerlo de esta manera, ¿verdad? Entonces tienes tu código, llamas a la función que esperas que lance una excepción, capturas el error, y luego haces alguna afirmación sobre los mensajes de error.

Solo quieres asegurarte de que, ya sabes, alguna parte de ese mensaje de error porque los errores, ya sabes, también agregan algún estándar al frente, por ejemplo, un error de dos puntos y solo quieres asegurarte de que tu mensaje de error esté ahí, ¿verdad? Y podemos hacer esto, ya sabes, con un índice de comprobación. Y luego, ya sabes, no queremos que sea menos uno porque significaría que no está ahí. Sin embargo, nuevamente, ese mensaje de error esperado no menos uno no nos ayuda mucho.

Nuevamente, afortunadamente para nosotros, Jest como un marco de pruebas que estoy usando aquí nos ofrece una afirmación que simplemente pasa una función que queremos lanzar y espera que lance un cierto mensaje de error. Ahora, nuevamente, la salida de error se ve ligeramente diferente. En primer lugar, vemos lo que esperábamos. Ahora vemos lo que recibimos en su lugar, mensaje personalizado. Y también nos señala directamente desde dónde se lanzó el error. Y esto puede, ya sabes, una vez más, darte más contexto para trabajar con tu código. Y luego solucionar ese error, con suerte.

Hay, ya sabes, probablemente muchos de ustedes que trabajan con DOM. Algunos de ustedes podrían estar trabajando con la biblioteca de pruebas. Y hay adiciones muy buenas a Jest. Jest DOM es una de ellas. Si estás trabajando con la biblioteca de pruebas, eso te brinda un montón de afirmaciones personalizadas para verificar los atributos de accesibilidad, los estados de la interfaz de usuario, habilitado, deshabilitado, habilitado, enfoque, todo este tipo de cosas. Pero todo esto cae en la misma categoría, ¿verdad? Mi sugerencia general sería, ya sabes, elige la afirmación que se acerque más a lo que realmente quieres hacer, ya sea que quieras verificar una propiedad, que quieras verificar un error, que quieras verificar un cierto estado de la interfaz de usuario, y luego ve con eso, ya sabes, en lugar de simplemente construir alguna forma de condición booleana y luego verificar que sea verdadera o falsa porque eso no te dará mucho.

Ok, esto concluye básicamente la primera mitad, ¿verdad? Estructura general de las pruebas. Hablamos de las afirmaciones y las descripciones de las pruebas y especialmente, ya sabes, trabajar solo con un caso de uso a la vez. Ahora veamos algo de código de prueba, ¿de acuerdo? Por ejemplo, esta prueba, funciona perfectamente. Sin embargo, hay mucho sucediendo aquí, ¿verdad? Entonces, básicamente esta prueba solo verifica que si cambiamos una entrada, nuestro controlador onChange se llame con la propiedad correcta. Pero, ya sabes, tenemos mucha configuración, muchas, ya sabes, interacciones sucediendo aquí abajo. Y la pregunta que haría es, ya sabes, ¿todas estas interacciones son necesarias? Y podría ser, ¿verdad? Y si es necesario, entonces en lugar de simplemente, ya sabes, escribirlo aquí, yo, ya sabes, seguiría adelante y extraería eso, por ejemplo, en un método, llámalo, por ejemplo, simulateChange, que tiene un valor. Y luego puedo mover esto aquí abajo, o simulateChange en su lugar. Entonces, toda la estructura de preparación, acción, estructura de esa prueba se volvió mucho, ya sabes, más limpia, ¿verdad? Y también esto tiene un nombre, ¿verdad? Queremos simular el cambio porque de eso se trataba este bloque, ¿verdad? Ahora, al extraerlo al método, darle a ese método un nombre adecuado, podemos simplemente hacer esto más claro para el lector. Sin embargo, veo mucho más. Por ejemplo, hay un onKeyDown, ya sabes, función definida aquí. Entonces ha pasado mucho tiempo desde que escuchamos que se pasa, pero nunca lo afirmamos. Entonces mi pregunta sería, ¿qué tan importante es, ¿verdad? Y esto, ya sabes, puede suceder especialmente si copias y pegas muchas pruebas porque esto podría haber sido importante en otra prueba de la que copiaste esto y nunca lo eliminaste, ¿verdad? Y al repetir esto, puedes inflar tus casos de prueba uno tras otro por eso personalmente siempre escribo pruebas desde el principio. Intento, ya sabes, no copiar y pegar en absoluto porque soy perezoso. Entonces, y mi pereza me obligará a escribir la menor cantidad de código y también, ya sabes, comenzar a extraer en métodos tan pronto como repita la misma estructura por segunda o tercera vez.

Entonces, y mi pereza me obligará a escribir la menor cantidad de código y también, ya sabes, comenzar a extraer en métodos tan pronto como, ya sabes, repita la misma estructura por segunda o tercera vez. Entonces uso mi pereza como una función forzada para pruebas más agradables, en esencia. Y también, dado que, ya sabes, supongamos que esto se escribió con el enfoque de rojo-verde-refactorizar, la prueba falló al principio. Luego implementamos algo, lo hacemos verde, ahora estamos de todos modos en la fase de refactorización. Entonces, esencialmente, cualquier cambio que podamos hacer en esta prueba que, ya sabes, la mantenga en verde, y yo espero esto, excepto tal vez eliminar la afirmación, es un cambio válido, ¿verdad? Entonces, aquí, por ejemplo, podría decir, simplemente eliminemos el onKeyDown y veamos qué sucede. Sí. Aún está en verde, y también podemos eliminar el valor inicial aquí porque eso también es, ya sabes, eso, creo que es importante, veamos. Descubramos si era importante o no. No, no parece serlo. Y solo para demostrártelo, si elimino el onChange aquí, escribo texto, pero ahora debería fallar. Sí, ahora la prueba falla. Entonces, aparentemente, ese no era un cambio que debería haber hecho. De acuerdo, con eso en mente, la lección a aprender aquí es, ya sabes, mantener las pruebas lo más pequeñas posible.

Sin embargo, y esto nos lleva al último paso, hay una cosa, ya sabes, que también hice al extraer esto, es como si esta parte del código estuviera presente en múltiples pruebas, entonces, ya sabes, me adheriría al principio DRY. Sin embargo, DRY puede ser peligroso en las pruebas y déjame mostrarte por qué.

Así que veamos este último ejemplo aquí. Básicamente, estas dos pruebas, ya sabes, una verifica que la propiedad onClick no se llama cuando el botón está desactivado y la otra verifica que se llama si el botón no está desactivado, ¿verdad? Y estas pruebas se ven muy similares, ¿verdad? Sin embargo, si miramos el renderizador, entonces vemos que este pasa la propiedad desactivada, este no, ya sabes, hacer clic en el botón es exactamente el mismo código. Sin embargo, ya sabes, ya es mínimo, así que tal vez, ya sabes, no tiene sentido extraer eso. Y luego la afirmación también es ligeramente diferente porque una tiene un `not` y la otra no. Sin embargo, el método onClick que definimos aquí es, ya sabes, esta línea de código es la misma en ambos casos de prueba. Así que podrías sentirte tentado de mantener esta prueba seca, moverla fuera de la prueba, ahora mover aquí, guardar, y ya sabes, seguimos un enfoque de rojo-verde-refactorizar. Entonces, si la prueba está en verde, todo está bien y la prueba se mantiene en verde. Entonces, este cambio debe ser un cambio válido. Sin embargo, cometimos un gran error y este error es que simplemente acoplamos esas dos pruebas y las acoplamos al extraer esto, porque esto es algo que es mutable. Ahí lo tenemos de nuevo, estado mutable compartido, ya sabes la frase, es la raíz de todo mal. ¿Verdad? Entonces, en este caso, al extraer el controlador OnClick, ahora esencialmente acoplamos ambas pruebas a él y peor aún, el orden de las pruebas de repente es importante porque si muevo esta prueba debajo de esta y veamos qué sucede, comienza a fallar. Sin embargo, no falla porque el código no funciona. Simplemente comienza a fallar porque este controlador OnClick aquí comienza a contar y se ha llamado cuando se ejecuta la primera prueba, almacena esto y luego si se ejecuta la segunda prueba, esta afirmación ya no es verdadera. Porque se ha llamado en esta prueba. Entonces acoplamos nuestras pruebas y ya no están aisladas y estos errores son realmente, realmente difíciles de depurar porque si comienzo, si aíslo esta prueba, volverá a funcionar. Y esto es una de las cosas más frustrantes que hago. Si veo un fallo en la prueba, pongo un `only` en algún lugar y luego la prueba comienza a funcionar y digo, maldición. Porque entonces tengo que realmente adentrarme en el código y averiguar, ok, ¿qué está pasando? Como, ¿dónde está el estado compartido? ¿Dónde, cómo puedo hacer que no sea compartido y separar esto?

Entonces mi sugerencia general es tratar de, cierta humedad de las pruebas, creo, es buena. Solo para evitar este tipo de escenarios aquí. Y esto casi concluye mi charla. Así que solo para recapitular, ¿cuáles son los cuatro puntos importantes para aprender aquí? El primer punto es, ya sabes, tratar de adherirse a un caso de uso por prueba. Esto es realmente importante. Un caso de uso no significa una afirmación, solo, ya sabes, un caso de uso. Luego trata de usar afirmaciones que coincidan realmente con lo que quieres expresar, ¿verdad? Para que si ocurre un error, el mensaje de error proporcione la mayor cantidad de contexto posible para el aspecto particular que estás probando. Luego, cuando escribas tus pruebas, tal vez no copies y pegues demasiado, ¿verdad? Mantén las pruebas concisas y limítalas solo a lo que realmente necesitan, ya sabes, para realizar su trabajo, ¿verdad? Esto te ayuda si, ya sabes, si necesitas adentrarte en el código de la prueba para no distraerte con todo lo demás que está allí y que no hace nada, ¿verdad? Lo último es, ya sabes, no trates de ser demasiado seco con tus pruebas, ya sabes, porque el aislamiento de las pruebas es más importante que, ya sabes, el código completamente seco. Cada prueba debe funcionar por sí misma y no debe depender de algo compartido globalmente porque eso simplemente, ya sabes, conlleva muchos peligros y errores difíciles de depurar. Eso es todo.

Muchas gracias por escuchar y nos vemos en el control de calidad. Adiós.

Hola, Filip. ¿Cómo estás? Gracias por la excelente charla. Muchas gracias. Disfruté mucho dando o grabando la charla. Genial. Genial.

Creo que primero podríamos analizar los resultados de la pregunta de la encuesta que presentaste en la mesa. Y en realidad, cuando estaba votando, pensé que faltaba una respuesta, que sería algo como: Me gusta hacer TDD, pero no lo hago la mayor parte del tiempo. Así que creo que esa fue la respuesta que faltaba, pero ¿qué opinas de los resultados? Me impresionó que al principio, las personas que lo usaban la mayor parte del tiempo estaban ganando, pero ahora hay algunas personas que lo intentaron y tuvieron problemas. Entonces, ¿qué piensas al respecto? Todavía me impresiona que usarlo la mayor parte del tiempo sea la segunda opción en la encuesta. A mí también. Realmente no me lo esperaba, aunque sí esperaba que algunos tuvieran problemas porque esa suele ser la respuesta que obtengo cuando pregunto a las personas si trabajan con TDD o no. Sí, pero parece una buena señal, ¿verdad? Absolutamente. Pero tal vez en el TestJS Summit, las personas estén un poco sesgadas. Es cierto. Eso es un buen punto.

Tenemos algunas preguntas de la audiencia. Así que voy a presentar la primera, que es de Mark sobre no usar la palabra clave 'end'. ¿Qué hay de los escenarios impulsados por tareas? Aquí está, él está hablando de las pruebas de IU cuando la configuración lleva una cantidad considerable de tiempo. Intentamos dividir los escenarios, pero terminamos con pruebas que tardan mucho en ejecutarse. Entonces, ¿hay excepciones a la prohibición de 'end'? Solo quería dar mi comentario antes de que respondas, que para mí, parece que hay algunos malos olores en el código de pruebas cuando no hay capacidad de prueba en la aplicación que te permita crear el estado de una manera más fácil. Cuando hablas de pruebas de IU y dependes de la IU para hacer todo. Pero me encantaría escuchar tu respuesta al respecto. Sí. Al final, también diría que depende, obviamente. Ninguna de mis reglas dice que solo se puede hacer de esta manera. Y si lo haces de manera diferente, entonces lo estás haciendo mal, por supuesto. Pero entiendo tu punto de vista muy bien.

Entonces, también te preguntaría, si tu sistema actual no te permite aislar casos de uso individuales, tal vez ese sea el problema en el que deberías enfocarte y tratar de convertirlo en un sistema que realmente pueda permitirte hacer esto. Porque al final, sigues teniendo los mismos problemas, ¿verdad? Si mezclas muchas cosas, está bien, puedes tener una prueba que se ejecute rápidamente, pero luego no te brinda tanto si falla. Pero nuevamente, si estas son todas las opciones, considera que es la mejor manera de hacerlo. Y, por supuesto, hazlo, ¿verdad? Porque es mejor que hacerlo manualmente, y cualquier prueba es mejor que no tener ninguna, según mi opinión.

Exactamente, sí. Pero sí, creo que planteaste un buen punto. No siempre tenemos que culpar a las pruebas. A veces falta la capacidad de prueba en la aplicación para permitirnos escribir pruebas más aisladas y más rápidas de ejecutar. Eso es genial.

Tenemos una pregunta de Elias. ¿Crees que siempre deberíamos usar TDD o solo para algunas características? Esa es una buena pregunta. Personalmente, siempre lo haría. Porque mi regla general es que si es una característica muy pequeña y sé exactamente lo que se supone que debe hacer, entonces no necesito hacer TDD, a lo que respondería. Y si es muy pequeña y muy fácil, entonces escribir una prueba para eso tampoco lleva mucho tiempo. Así que, ya sabes, simplemente hazlo. Y de todos modos estarás en el lado seguro. Si es más grande y al escribir la prueba te das cuenta de que aún necesitas entender partes de ella. Nuevamente, la prueba, al escribir la prueba de antemano, simplemente te ha ayudado a comprender que te falta información o que necesitas prototipar un poco más para averiguar qué quieres lograr realmente. Así que siempre lo hago porque creo que siempre te ayuda mucho. Sí, eso es una buena perspectiva sin duda.

Tenemos una pregunta de Chris Christiana. ¿Crees que es una mala práctica definir constantes inmutables comunes, como el texto de los botones, en el bloque de descripción? ¿Qué opinas al respecto? Personalmente, una vez más, depende. Si es un texto común, una configuración común, por ejemplo, como una configuración predeterminada, si tiene un buen nombre, por ejemplo, uso prefijos como 'default' u otra cosa para dejar claro que esto es algo que nunca cambia y que solo necesito, entonces creo que está totalmente bien. Sin embargo, si comienzas a extraer constantes en las descripciones y solo se utilizan en una o dos pruebas y las demás no las necesitan, entonces, ¿por qué están fuera? Podría estar complicando demasiado las cosas. Mi regla general es que me gusta volver a probar de principio a fin y entender eso. Si llego a un punto en el que soy un compilador y es como, bueno, aquí está la línea, la variable, ¿dónde está esta variable? Y luego tengo que buscar en el árbol para averiguar qué hay en esta cosa ahora, entonces prefiero tenerlo en línea con la prueba y todo está bien. Sí, exactamente. Veamos, otra pregunta aquí. ¿Cómo sabes dónde poner la prueba cuando el código es completamente desconocido? Esa también es una buena pregunta. Lo que hago es que si el código es completamente desconocido, simplemente lo pruebo. Hago un experimento para averiguar con qué estoy lidiando. Y una vez que entiendo suficiente el código, simplemente descarto todo eso y vuelvo a comenzar con la prueba.

Y lo que sucede es que el 90% del tiempo termino con una solución mejor que el prototipo que acabo de escribir. Así que sí, la parte importante realmente es descartar todo lo que acabas de hacer, y luego volver a la seguridad con TDD. Eso tiene total sentido.

Tenemos otra pregunta de Elias, ¿crees que solo el equipo de desarrollo debería hacer TDD o también debería hacerlo el equipo de QA de automatización? Yo, como QA, también hago TDD. Así que quiero decir, cuando estoy escribiendo una prueba, a veces la escribo de tal manera que a veces necesitaré una función externa que haga algo por mí. Escribo el nombre de la función. Y después la implemento. Así que podría decir que esto es algo similar a hacer TDD. ¿Qué opinas?

Absolutamente. Y quiero decir, siempre y cuando el trabajo de automatización sea probado, ¿por qué no definir tus criterios de aceptación de antemano? Creo que he refactorizado un montón de scripts de S-H a, no sé, JavaScript o TypeScript o Python o lo que sea, solo para tener un ejecutor de pruebas con el que me sienta cómodo, y puedo hacer exactamente lo mismo, tal vez un poco más lento, pero luego puedo definir mis casos de prueba por escenarios. Y es como, vale, esto se carga en el bucket correcto de AWS, por ejemplo, y esta cosa, ya sabes, crea el archivo de configuración correcto o lo lee de algún lugar. Y esto, ya sabes, en todo el proceso de extremo a extremo, ya sabes, donde puedas editar la prueba, edita la prueba, porque te va a salvar en algún momento. Eso es completamente cierto.