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

Rate this content
Bookmark

Es una trampa` - una llamada o sensación con la que todos podríamos estar familiarizados, no solo cuando se trata de Star Wars. Señala un momento repentino de darse cuenta de un peligro inminente. Esta situación es una excelente alegoría para una desagradable realización en las pruebas. ¿Imagina tener las mejores intenciones cuando se trata de las pruebas pero aún así terminar con pruebas que no le brindan ningún valor en absoluto? ¿Pruebas que se sienten como un dolor para lidiar con ellas?


Cuando se escriben pruebas de frontend, hay muchas trampas en el camino. En resumen, pueden llevar a una mala mantenibilidad, un tiempo de ejecución lento y, en el peor de los casos, pruebas en las que no se puede confiar. Pero no tiene que ser así. En esta sesión, hablaré sobre los errores comunes de los desarrolladores (incluyendo los míos), al menos desde mi experiencia. Y, por supuesto, sobre cómo evitarlos. Después de todo, las pruebas no tienen por qué ser dolorosas.

20 min
19 Nov, 2021

Video Summary and Transcription

Esta charla explora los puntos problemáticos y las mejores prácticas en las pruebas de software, enfatizando la importancia de la simplicidad y la comprensibilidad en el diseño de las pruebas. Se discuten técnicas como la regla de tres partes para los títulos de las pruebas, el patrón triple-A para la estructura de las pruebas y el uso de nombres claros y descriptivos en las pruebas. La charla también destaca las trampas de los detalles de implementación en las pruebas y el uso de tiempos de espera fijos. El orador fomenta el trabajo en equipo y el aprendizaje de la experiencia para mejorar las prácticas de pruebas.`, `seotitle`: null, `seodescription`: nul

Available in English

1. Introducción a las pruebas y trampas

Short description:

Hola a todos y bienvenidos a mi sesión aquí en TestJS Summit este año. Me alegra mucho que estén dedicando su tiempo conmigo para aprender sobre todas las cosas que yo mismo arruiné. Permítanme comenzar de otra manera. Soy Ramona y bienvenidos al episodio de estreno de Moe presenta FarmEarth Test. Trabajo como desarrollador de software en Shopware, que es una empresa que ofrece una plataforma de comercio electrónico de código abierto. Conozco tanto la perspectiva del tester como la del desarrollador, y me esfuerzo por mejorar la experiencia de ambos. 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. ¡Es una trampa! Es realmente una cita memorable, dicha por el Almirante Ackbar, líder de los rebeldes Mon Calamari. Es una buena alegoría cuando se trata de las pruebas. Las pruebas tienen muchas ventajas y beneficios, 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.

Me alegra mucho que estén dedicando su tiempo conmigo para aprender sobre todas las cosas que yo mismo arruiné. Sí, lo sé, suena duro. Pero sinceramente, espero aprender de mis errores pasados junto con todos ustedes. Así que muchas gracias por estar aquí y empecemos, ¿de acuerdo?

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.

2. Testing Pain Points and Simplicity

Short description:

Cuando se trata de mis comienzos, mi carrera como tester o desarrollador, pienso en tres puntos dolorosos: pruebas lentas, pruebas difíciles de mantener y pruebas que no aportan valor. Permítanme mostrarles mis mayores fracasos en cuanto a pruebas y cómo corregirlos. Lo más importante es evitar pruebas que consuman espacio mental. Las pruebas deben ser diseñadas de manera simple en todos los casos.

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.

3. Test Design and Comprehensibility

Short description:

Las pruebas deben ser diseñadas de manera simple en todos los casos. Utilice menos o ninguna abstracción dentro de sus pruebas para mantenerlas comprensibles. Mantenga sus pruebas mínimas y pruebe solo lo necesario. Este principio se puede aplicar a todos los ejemplos siguientes.

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.

4. Mejorando los títulos de las pruebas con la regla de las tres partes

Short description:

Veamos un ejemplo. Al escribir pruebas, es crucial tener títulos claros y comprensibles. La regla de las tres partes de Woi-Ashiwab puede ayudar con esto. Sugiere estructurar las pruebas en tres partes: qué se está probando, bajo qué circunstancias y cuál es el resultado esperado. Esto asegura que el propósito de la prueba sea claro y fácilmente comprensible. Siguiendo esta regla, puedes crear títulos de prueba que brinden información inmediata sobre el propósito y el resultado esperado de la prueba.

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.

5. Estructura de las pruebas y nombres de marcador

Short description:

Observa esta estructura de prueba. Es un desastre. Pero podemos hacer que sea más fácil de entender utilizando el patrón triple-A: organizar, actuar, afirmar. Este patrón ayuda a estructurar las pruebas en tres partes: configuración, ejecución de la prueba y afirmaciones. Siguiendo este patrón, las pruebas se vuelven más simples y comprensibles. Otro error a evitar es usar nombres de marcador ambiguos en las pruebas. En su lugar, utiliza nombres claros y descriptivos para mejorar la legibilidad de las pruebas.

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.

6. Mejores prácticas de pruebas

Short description:

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. 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. ¿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. Por lo tanto, no debes probar detalles de implementación en absoluto. En su lugar, debes usar otras cosas. 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.

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.

QnA

Reflexiones finales y preguntas

Short description:

Les presenté mis dos favoritos para usar. El primero es esperar cambios en la interfaz de usuario de su aplicación, por ejemplo, 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. 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 pruebas. Puede ser mucho trabajo, especialmente cuando se trata de código heredado, y puede requerir un cambio de mentalidad para el diseño 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. 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í. 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.

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.

Principios de Pruebas y Uso de Selectores

Short description:

Cuando se trata de decidir entre el principio dry y pruebas comprensibles, puede ser un desafío. Como desarrollador, prefiero el principio dry, pero como tester, priorizo tener pruebas comprensibles. Si se utiliza un fragmento de código en varias pruebas, crear un comando personalizado con un nombre descriptivo puede lograr un equilibrio entre dryness y comprensibilidad. En cuanto a los selectores, el uso de selectores CSS puede ser propenso a cambios, por lo que usar cadenas o atributos de datos puede ser más confiable. Los atributos de datos con convenciones de nombres claros pueden garantizar que las pruebas fallen por las razones correctas y reducir la carga de trabajo del desarrollador. Al comparar arrange, act, assert y given, when, then, depende del contexto. Mientras que arrange, act, assert es adecuado para pruebas unitarias, given, when, then es más apropiado para pruebas de integración o cuando se verifica el estado antes y después de los componentes.

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.

Secuencias de Asertos Repetidos en Pruebas End-to-End

Short description:

En las pruebas end-to-end, puede ser necesario tener secuencias de asertos repetidos, pero es importante que la prueba sea fácil de leer. Considera usar comentarios para nombrar secciones y ayudar a otros desarrolladores a comprenderla.

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.

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 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

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.