¡Es una trampa! - Trampas comunes en las pruebas y cómo solucionarlas

Permítanme comenzar de otra manera. Soy Ramona y bienvenidos al episodio de estreno de Moe presenta FarmEarth Test. Un dato curioso, Moe es un apodo para mí. Pero dejemos de ser tontos y pongámonos serios. Trabajo como desarrollador de software en Shopware, que es una empresa que ofrece una plataforma de comercio electrónico de código abierto. Pero también tengo experiencia en aseguramiento de calidad. Conozco tanto la perspectiva del producto como la del desarrollador, y me esfuerzo por mejorar la experiencia de ambos. Llamémoslo experiencia del desarrollador y del tester por igual. Y básicamente esta es la razón por la que empecé a pensar en esta sesión, esta charla.

Para ir al grano, pensemos en la siguiente situación o mejor dicho, es más un pensamiento. Hay un par de películas que me encantaba ver en mi infancia. Incluso como adulta las he vuelto a ver numerosas veces. Y una de esas franquicias es Star Wars. Y hay una cita en particular de la película Star Wars episodio 6 de 1983, que es El Retorno del Jedi, que se me quedó grabada en la mente. Y es esta. ¡Es una trampa! Bueno, dejando de lado mis terribles habilidades de imitación. Es realmente una cita memorable, dicha por el Almirante Ackbar, líder de los rebeldes Mon Calamari. Y fue dicha durante la Batalla de Endor, donde la Alianza movilizó sus fuerzas en un esfuerzo concertado para destruir la Estrella de la Muerte. Y Ackbar se encuentra con una emboscada inesperada allí, lo que lo lleva a exclamar esta cita. Así que sí, es una buena cita, ¿verdad? ¿Qué piensan? Se preguntarán qué tiene que ver con las pruebas. Y sí, creo que tiene algo que ver con las pruebas. Es una buena alegoría cuando se trata de las pruebas. Las pruebas tienen muchas ventajas y beneficios, y no creo que necesite convencerlos de eso aquí en esta sesión. Pero todos esos valores, todas esas cosas maravillosas cuando se trata de las pruebas pueden ser opacadas por puntos dolorosos causados por diversas razones. Muchos de ellos pueden considerarse trampas y pueden sentirse como una emboscada. Cosas que hiciste con la mejor intención, por supuesto, pero que resultan ser dolorosas a largo plazo o incluso antes.

Bien, cuando se trata de mis comienzos, mi carrera como tester o desarrollador, pienso en tres puntos dolorosos, especialmente cuando se trata de, aquí, dolor. El primero son las pruebas lentas, que pueden ocurrir por diversas razones. Y pueden imaginar, si quieren terminar una funcionalidad o una tarea o un ticket, y desean fusionar su pull request con ansias, pero necesitan esperar a que se ejecuten los pipelines, eso es terrible.

En segundo lugar, y tal vez más importante, pienso en pruebas que son difíciles de mantener. Por ejemplo, una prueba que no entiendo cuando la veo meses o incluso años después. Incluso compañeros de equipo me preguntan qué pensaba que quería lograr con esta prueba, así que, bueno, creo que suceden cosas malas, ¿verdad? Pero no es el peor punto doloroso que he sentido cuando se trata de trabajar con pruebas. Se trata de aquellas pruebas que no aportan ningún valor, ningún resultado claro en absoluto. Pueden llamarlas hyzm-fails o hyzm-tests, como el famoso bug hyzm, que solo ocurre si apartas la mirada, no depures los resultados. Y está el jefe final, las pruebas inestables, que no son determinantes, pruebas que no logran entregar el mismo valor correcto entre compilaciones. Imaginen una prueba que pasa la primera vez y falla la segunda, y pasa la tercera, eso dice que no se puede confiar, ¿verdad?

Pero bueno, no tiene que ser así. Permítanme mostrarles mis mayores fracasos cuando se trata de pruebas y cómo corregirlos. Cómo, sí, qué tener en cuenta al escribir buenas pruebas y evitar estas trampas. Debido al límite de tiempo, no puedo mencionar todos ellos, pero hablemos de otros, como algunos que encontré o su experiencia más adelante en la sesión de preguntas y respuestas, o incluso más adelante. La primera y más importante cosa en mi mente es la siguiente situación. Por favor, mírenla primero. Tal vez se sientan familiares con ella. Bueno, piensen en su cerebro haciendo una tarea, codificar. Y su cerebro está lleno con el código de producción principal. Y no les queda espacio mental para ninguna complejidad adicional. Cada tarea que se añada no debe consumir espacio mental o agotarlos. De lo contrario, les resultará doloroso. Así que consumir más espacio mental va en contra de la intención de las pruebas, e incluso puede llevar al equipo a abandonar las pruebas por completo en el peor de los casos. Por lo tanto, evitar que las pruebas consuman espacio mental es lo más importante en las pruebas en mi opinión. Y no estoy solo en eso. Joni Gilbert lo describe como la regla de oro. Y es la siguiente. Básicamente, mantenlo estúpidamente simple. Las pruebas deben ser diseñadas de manera simple en todos los casos. Y no importa si estamos hablando de pruebas unitarias o de extremo a extremo. Nuestro objetivo debe ser el siguiente.

Uno debería mirar su prueba y comprender su intención al instante. Sin tener que pensarlo, básicamente. Así es, las pruebas no son totalmente como el código de producción. No del todo. Y sí, sé que se debe tratar el código de prueba con el mismo cuidado que se hace con el código de producción. Pero algunas best practices aplicadas al código de producción no son adecuadas para las pruebas o están en conflicto con las pruebas. Por ejemplo, cuando pienso en la duplicación o el principio DRY. Así que por favor, trate de utilizar menos o ninguna abstracción dentro de sus pruebas, para mantenerlas comprensibles. Esto también significa tener precaución cuando se trata de comandos o objetos de página en NGINX, por ejemplo. Me gusta describirlo como un diseño de prueba plano o mínimo. Por lo tanto, testing solo lo necesario también forma parte de esto. En este caso, mantendrá sus pruebas comprensibles y agradables de trabajar. Y este es un principio que se puede aplicar básicamente a todos los ejemplos siguientes.

Entonces, estoy hablando de ejemplos, ¿verdad? Echemos un vistazo a ellos. Observa este pequeño fragmento de código. Especialmente cuando se trata del título de la prueba. Es solo un fragmento. Pero también es aplicable a las pruebas de extremo a extremo. Cuando miras esta prueba, ¿sabes qué quiere lograr? Por ejemplo, si miras el registro de tu prueba y esta falla, ¿sabes de qué se trata o qué podría estar mal en ella? Bueno, debería arrojar un error. ¿Pero qué error? ¿Cuándo debería arrojarse? ¿Algo más? Recuerda nuestra regla de oro. Deberías saber al instante qué hace tu prueba. Entonces, ¿necesitamos mejorarlo, verdad? Echemos un vistazo. Esta es la regla de las tres partes de Woi-Ashiwab, que podría ser útil en este caso. Te ayudará a mantener claro qué quiere cubrir y lograr tu prueba. Es bien conocida en las pruebas unitarias, pero tal vez no sea tan malo tenerla en cuenta cuando se trata de pruebas de extremo a extremo o de integración. La regla de las tres partes básicamente dice que debes tener una prueba que contenga tres partes. Uno, ¿qué se está probando? En este caso, es la propiedad. Dos, ¿bajo qué circunstancias y escenario probamos, que es el uso de la propiedad obsoleta en nuestro ejemplo. Y tres, ¿cuál es el resultado esperado de la prueba? En este caso, el error arrojado. Entonces tenemos este pequeño título aquí, que ya no es tan pequeño, pero es más comprensible. Y si piensas en títulos de prueba más largos, el gato largo es largo, lo siento, el nombre de la prueba es largo. Al gato largo le gustan los títulos de prueba largos porque puedes ver el resultado de la prueba a primera vista. Y no necesitas leer todos los registros o el código fuente para entender qué está mal en esta prueba.

Muy bien, siguiente error. Observa esta prueba. ¿La ves y la entiendes a primera vista? Si es así, debo felicitarte, pero si no, eso es totalmente normal y no hay problema en absoluto, porque esta estructura de prueba es un desastre. Verás, las declaraciones, las afirmaciones y las acciones realmente no son necesarias sin ninguna estructura en absoluto. Entonces, ¿cómo podemos cambiar esta prueba para que sea más fácil de entender? Bueno, me gusta usar el patrón triple-A, que es una abreviatura de organizar, actuar, afirmar. Nuevamente, esto es relevante para las unit testing, así que usaré un ejemplo aquí, pero sí, no es tan bueno para las pruebas de extremo a extremo, que tienden a ser un poco más largas, pero aún así vale la pena mencionarlo aquí. El patrón triple-A dice que debes estructurar tus pruebas en tres partes. Primero, la parte de organizar, que se encarga de la configuración para llevar el sistema al escenario que la prueba pretende simular. Piensa en variables duplicadas o simuladas, por ejemplo. El segundo es sobre la ejecución de tu prueba. Básicamente, la parte de actuar. Ejecuta tu unidad bajo prueba, realiza tus pasos, acciones, etc. para llegar al estado de resultado. Y tercero, la parte de afirmar, que es bastante autoexplicativa. Realiza las afirmaciones y comprobaciones de tu escenario de prueba dentro de ella, lo que hace que el patrón triple-A sea otra forma de diseñar tus pruebas de manera simple y única. Y básicamente puedes entender la prueba a primera vista, lo cual es realmente, realmente importante.

Muy bien, siguiente. Otra diapositiva, otro error. Y tenemos a BB-8 de Star Wars como invitado. Y encontró un nombre que puede resultarnos familiar. Pero no a él, no a BB-8. Es FUBAR. Bueno, nosotros como desarrolladores sabemos que FUBAR a menudo se usa como un nombre de marcador. Pero si lo ves dentro de una prueba, ¿sabes directamente qué significa? Nuevamente, de esta manera tu prueba puede ser más difícil de entender a primera vista. Así que debemos evitar eso. Pero, ¿qué debemos hacer en su lugar? Echemos un vistazo. En este caso, te presento una pequeña prueba de cypress. Así que es una prueba de extremo a extremo en este caso. Pero este consejo no se limita a eso. También puedes usarlo en las pruebas de integración de unit testing.

Esta prueba debe verificar si se puede crear y leer un producto. Por lo tanto, quiero usar nombres y marcadores de posición conectados a un proyecto real. Por ejemplo, cuando se trata de la camiseta, uso 'camiseta Akbar' porque es una camiseta con Akbar. Y cuando se trata del fabricante, quiero usar 'Base Company' como nombre. Así puedes ver que estoy tratando con un producto, por ejemplo.

Si no quieres inventar todos los nombres por ti mismo, puedes usar Faker para generar datos o incluso importarlos desde un estado de producción. Así que tal vez veas que quiero seguir la regla de oro que mencionamos incluso cuando se trata de los nombres. Nuevos trabajos, mismas pruebas.

¿Notaste estos selectores aquí? Son selectores CSS y podrías decir ahora, 'Bueno, puedo tener selectores CSS únicos, ¿verdad? ¿Por qué son problemáticos?' Bueno, porque son propensos a cambios. Si, por ejemplo, refactorizas la aplicación y cambias las clases, la prueba puede fallar incluso si no introdujiste un error en la prueba. Fallar sin un error es un falso negativo, no proporciona un informe confiable sobre la aplicación, ya que simplemente cambiaste la implementación y no informa un error, ¿verdad? Esta trampa se refiere principalmente a las pruebas en este caso particular. Pero en otras circunstancias también puede aplicarse a las pruebas unitarias tan pronto como uses selectores. Así que debes prestar atención a los selectores, diría Yoda.

No debes probar detalles de implementación en absoluto. En su lugar, debes usar otras cosas. Por ejemplo, en lugar de un selector CSS, intenta probar algo a lo que un usuario prestaría atención. Por ejemplo, una pequeña cadena que ves dentro de tu aplicación, o un encabezado, o las palabras dentro de un botón. O incluso mejor, elige selectores que sean menos propensos a cambios, por ejemplo, atributos de datos. Si refactorizas tu aplicación, es posible que cambies algunas clases o estilos CSS, pero cambiar los atributos de datos, especialmente si los nombras como 'test' o 'CY', no es tan común, por lo que son menos propensos a cambios.

Por último, pero no menos importante, hay un tema del que no puedo enfatizar lo suficiente, así que necesito presentarlo también como una trampa aquí. Se trata de estos tiempos de espera fijos. Como esperar medio segundo cada vez. Y peor aún, está en un comando aquí, por lo que se ejecutará con demasiada frecuencia. Y en el mejor de los casos, ralentizará la prueba demasiado. Y no es necesario en absoluto, porque nuestra aplicación puede ser más rápida. Pero en el peor de los casos, esperaremos muy poco tiempo y causaremos inestabilidad. Afortunadamente, hay muchas cosas que puedes hacer para evitar las trampas de los tiempos de espera fijos. Echemos un vistazo. Todas las formas se centran en esperar dinámicamente, y prefiero métodos más deterministas que la mayoría de las plataformas proporcionan.

Les presenté mis dos favoritos para usar. El primero es esperar cambios en la interfaz de usuario de su aplicación, por ejemplo, animations detener las animaciones, hacer desaparecer un spinner de carga o cargar cualquier cosa. Otra posibilidad sería esperar las solicitudes de la API. Cypress ofrece características útiles para hacer eso. De esta manera, su prueba se mantendrá estable y confiable mientras administra el tiempo de manera eficiente, como este chico malo aquí.

Volvamos al Almirante Akbar. La Batalla de Endor resultó ser un éxito, por supuesto, con trabajo en equipo y un par de contramedidas incluidas. Relacionemos eso con las testing. Puede ser mucho trabajo, especialmente cuando se trata de código heredado, y puede requerir un cambio de mentalidad para el design de pruebas o mucha refactorización, pero vale la pena al final y sentirás las recompensas.

Lo más importante, realmente, quiero que recuerden, es referirse a la regla de oro de la que hablamos anteriormente. Todos los ejemplos se basan en eso. Todos los puntos problemáticos surgen de ignorarlo. Se trata de mantener sus pruebas fáciles de leer, mantenerlas y comprenderlas. Es una oración que quiero que recuerden de esta charla. Una prueba debe ser un asistente amigable, no un obstáculo para usted. Las pruebas deben sentirse como una rutina, no como resolver una fórmula matemática compleja o algo así. Así que demos lo mejor de nosotros para lograr eso. Miren, R2D2 aquí está atrapando errores con facilidad, y quiero que ustedes también lo sientan. Así que lidiar con las pruebas se siente limpio y divertido, y no agotador, ¿verdad? Entonces, sí... ¿Qué más puedo decir ahora? Gracias. Gracias por su tiempo y por escucharme. Y si tienen preguntas o desean discutir otras trampas que puedan ocurrirles o trampas que yo haya experimentado, únanse a la sesión de preguntas y respuestas o hablen conmigo en esta conferencia o después en Twitter o básicamente donde me encuentren. Así que mantengamos eso y nos vemos la próxima vez. ¡Adiós!

¿Qué opinan de los resultados, Almona? ¡Bienvenidos! ¡Hola a todos! Me siento realmente aliviado porque la mayoría de las personas respondieron de la misma manera que yo. He experimentado todo eso, como habrán notado, y es maravilloso no sentirme tan solo o como un idiota porque cometí tantos errores y espero que podamos aprovechar al máximo y aprender juntos y discutir juntos y sí, ¡veamos! Me gustan las lecciones que mencionaron hoy, definitivamente aprender de la experiencia y de toda la situación en la que nos encontramos hoy.

Movámonos a la pregunta, ya tenemos algunas en Discord, Sev estaba saludando y preguntando si tienes una opinión sobre el principio dry, no repetirte versus usar frases descriptivas y significativas cuando se trata de pruebas end-to-end. En otras palabras, si usas un fragmento de código en varias pruebas, ¿simplemente lo copiarías y pegarías para mantenerlo simple o crearías un comando personalizado para ello? Me encanta esta pregunta, porque es una lucha que yo mismo siento mucho, porque como desarrollador, por supuesto, me gusta decidir a favor del principio dry, para no repetirme demasiado. Pero como dije, como tester y también como desarrollador, tener pruebas comprensibles es lo más importante. A veces diría que no le des demasiado peso al principio dry y más a entender tus pruebas. Creo que si uso un fragmento de código en varias pruebas y no es un fragmento de código grande, usaría un comando personalizado, pero haría todo lo posible para nombrarlo de una manera realmente descriptiva y usar alguna documentación, por ejemplo, definiciones para autocompletar y cosas así, que se considera duplicado, pero creo que es realmente importante en este caso, para que todas las personas que vean este comando personalizado sepan de inmediato de qué se trata y qué hace. Así que puedes tenerlo comprensible y tener algo de dryness dentro de tus pruebas. Creo que es lo mejor en el medio, pero sé que es realmente, realmente difícil decidir a favor de uno u otro. De hecho, es difícil estar en el medio, pero a veces es el buen lugar para usarlo.

Liaz se preguntaba cómo obligar a los desarrolladores frontend a usar selectores. Creo que te refieres a usar selectores en lugar de cadenas o cualquier otra cosa, así que cuando se trata de selectores, es realmente importante distinguir qué selector usas. Cuando se trata de selectores CSS, preferiría usar cadenas o esperar a cualquier texto que el usuario vería en tu aplicación, porque los selectores CSS son propensos a cambios. Y esto podría ser algo que te dé algunas pruebas fallidas, incluso si no hay nada roto dentro de tu aplicación. Pero si estás usando otros selectores, como por ejemplo, atributos de datos, de los cuales soy un gran fanático, puedes hacer que sepan que no necesitarán actualizar sus pruebas tanto, porque cuando se trata de atributos de datos, y especialmente si los nombras como atributos de datos CY para Cypress, o cualquier otra frase descriptiva, un desarrollador que trabaje en tu código sabe que está destinado a pruebas y no lo cambiará. Entonces tus pruebas fallarán por las razones correctas y no solo por una clase desactualizada o algo así, lo cual es menos trabajo para el desarrollador, ¿verdad? Creo que ese podría ser un argumento maravilloso para convencerlos. Definitivamente, podemos ganarlos de nuestro lado con eso, en efecto.

Martine, oh dios mío, está vivo, preguntaba cómo compararías arrange, act, assert, lo siento, arrange, act, assert con given, when, then, y cuál de ellos usarías en qué situación. ¿Has encontrado alguna trampa con esto? Bueno, estoy muy contento de que hagas esta pregunta, Martine, porque eso fue lo que necesitaba dejar fuera de mi presentación debido al tiempo. Escribí un artículo al respecto, que algunas pruebas en mi trabajo diario, estoy trabajando en una aplicación enorme en el sector de comercio electrónico, que tiende a ser bastante conflictiva. E incluso en las pruebas unitarias, a veces se necesita un poco más de contexto en la prueba de lo que deberías tener cuando se trata de pruebas unitarias. Entonces, para empezar, no deberías llamarlas pruebas unitarias, pero cuando se trata de pruebas de integración en Jest o algo así, a veces necesitas probar el DOM, lo que a veces requiere que verifiques los estados antes y después de tu componente, por ejemplo. Y en este caso, arrange act assert no es algo bueno para usar, porque básicamente es realmente difícil encajar tus pruebas dentro de la estructura en este caso. Incluso given, when, then es más adecuado en este caso cuando se trata de pruebas de integración o si necesitas algunas sesiones en el estado antes y después. Así que puedes considerarlo de esa manera. Arrange en mis pruebas, creo que es lo que estoy dando. Así que todo lo que necesitas organizar es la parte dada. Act en mis pruebas. Creo que eso es cuando sucede algo.

Entonces esa es la parte intermedia. Y asertar los resultados. Así que en este caso, puedes hacer los asertos en el DOM en la parte dada y aún está bien. Y sigue siendo una estructura válida. Y ya no violará el AAA en este caso. De hecho, Maria, Maria K85 se preguntaba si se considera una mala práctica tener secuencias de asertos repetidos en un solo caso. Un ejemplo sería llenar un formulario, enviarlo, esperar que los data se envíen, hacer clic en editar y esperar que el formulario vuelva a estar activo. Creo que depende del propósito que le des. Si estás escribiendo una prueba de unidad bastante corta o una prueba de integración corta, consideraría, como dijo Martin, puedes usar otra estructura, pero cuando se trata de pruebas end-to-end, no puedes evitar usar esas secuencias de asertos. Entonces, en este caso, creo que podemos flexibilizar la regla y decir que está bien, siempre y cuando sea fácil para ti leer tu prueba. Así que tal vez usa algunos comentarios para nombrar algunas secciones para que los otros desarrolladores no tengan dificultades para entender tu prueba. En efecto. Sí, sería así. Bueno, otro sería el patrón que mencionaste, el AAAA. Siempre es una buena idea, ¿o hay algunas otras excepciones que veas allí? Sí, creo que ya lo hemos cubierto un poco cuando se trata de pruebas de integración, ¿verdad? Solo necesitas hacer asertos antes de los otros estados de tu aplicación, de tu componente o unidad, sea cual sea tu unidad. Sugeriría no usar el patrón de dos vías a favor de given-when-then u otras cosas. Un pequeño dato curioso cuando se trata de given-when-then. Es un poco tomado del BDD y fue algo interesante porque algunos desarrolladores en mi equipo no les gusta usar BDD para pruebas end-to-end, pero usan given-when-then para pruebas de unidad. Así que, un poco de doble estándar, creo. Bueno, en este caso sería una buena idea usar esas cosas o poner un poco más de énfasis en usar comentarios y saltos de línea cuando se trata de pruebas end-to-end. De acuerdo, gracias. Sobre las pruebas inestables, ¿cuál fue la trampa más dolorosa que experimentaste en esta área? Estoy muy agradecida de que sea la segunda respuesta más votada en la encuesta porque realmente, realmente tuve pesadillas cuando se trata de este tema. Mi mención honorífica cuando se trata de trampas en las que caí fue un problema ambiental, más o menos dependencias cruzadas porque usaba Nightwatch en ese entonces junto con el navegador de Google y, por lo tanto, usaba Google WebDriver y hubo un problema en, creo que era WebDriver, que no pudimos solucionar debido a varias razones. No pudimos actualizar Nightwatch. Entonces, las dependencias, bueno, se desgarraron y, sí, llevaron a algunas fallas dentro de mis pipelines y depurar eso fue realmente doloroso, y especialmente me llevó a cambiar los frameworks de prueba más adelante. Junto con el entorno Docker, que tenía algunos problemas de red, a veces sí, a veces no, eso fue realmente doloroso y para superar esta mala situación usamos retreading GitLab, de lo cual no soy un gran fanático, pero no sabía cómo solucionarlo hasta que pudiéramos actualizar. Así que realmente me avergoncé de esta solución, pero no ayudó, así que fue realmente doloroso. Pero ya pasó porque a veces pudimos actualizar y más tarde cambiamos de frameworks, así que sí. Bueno, una solución siempre es bienvenida. A veces no es la perfecta o tal vez la más fácil, pero es bueno que esté solucionado. Y tuvimos a David Burns anteriormente de WebDriver, así que si podemos presionar allí, pedir una solución será aún mejor para volver al inicial, hacer conexiones en conferencias. Muchas gracias, Ramona, por la charla. Gracias. Y diapositivas increíbles. Realmente aprecio la creatividad que le pusiste. Gracias por estar con nosotros. Gracias.