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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

El patrón triple-A es una metodología para estructurar pruebas en tres partes: organizar, actuar y afirmar. Este enfoque ayuda a clarificar y simplificar la ejecución y verificación en las pruebas.

Ramona es una desarrolladora de software que trabaja en Shopware, una empresa de plataforma de comercio electrónico de código abierto. Tiene experiencia en desarrollo de software y aseguramiento de calidad, conociendo las perspectivas de producto y desarrollador.

Moe presenta FarmEarth Test es el nombre del episodio de estreno donde Ramona comparte sus experiencias y aprendizajes como desarrolladora y tester. 'Moe' es un apodo para Ramona.

Ramona menciona la cita '¡Es una trampa!' de El Retorno del Jedi como una alegoría para describir cómo las pruebas de software pueden tener ventajas ocultas, pero también trampas que pueden resultar dolorosas si no se manejan con cuidado.

Los errores comunes en las pruebas incluyen pruebas lentas, pruebas difíciles de mantener, pruebas que no aportan valor claro y pruebas inestables que no son determinantes.

Ramona sugiere mantener las pruebas simples, evitar la duplicación innecesaria, usar menos abstracción dentro de las pruebas y aplicar un diseño de prueba plano o mínimo. También enfatiza la importancia de esperar dinámicamente en las pruebas para manejar eficientemente el tiempo.

La 'regla de oro' que Ramona menciona es mantenerlo estúpidamente simple, lo que implica que las pruebas deben ser diseñadas de manera simple para que cualquiera pueda entender su intención y funcionamiento rápidamente.

Ramona recomienda usar nombres y marcadores de posición relacionados con el proyecto real y evitar selectores CSS propensos a cambios, sugiriendo en su lugar el uso de atributos de datos menos susceptibles a modificaciones.

Según Ramona, se debe evitar probar detalles de implementación, como selectores CSS, porque pueden cambiar frecuentemente y causar fallas falsas en las pruebas. En su lugar, recomienda centrarse en elementos que los usuarios finales experimentarían.

Ramona Schwering
Ramona Schwering
20 min
19 Nov, 2021

Comments

Sign in or register to post your comment.
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

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de Aplicaciones Web con Playwright
TestJS Summit 2022TestJS Summit 2022
20 min
Pruebas de Aplicaciones Web con Playwright
Top Content
Testing web applications with Playwright, a reliable end-to-end testing tool. Playwright offers fast execution, powerful tooling, and support for multiple languages. It provides precise selectors, web-first assertions, and code generation for easy testing. Playwright also offers features like live debugging, tracing, and running tests on CI. The future of Playwright aims to make testing easy and fun, with a focus on creating frustration-free web experiences.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.