Escribiendo Buenas Pruebas para Aplicaciones Vue (e2e vs. Pruebas de Componentes, Características de una Prueba *Buena*)

Rate this content
Bookmark

La aparición de las SPAs, y por lo tanto, el código del lado del cliente con mucha lógica, cambió drásticamente el juego para los desarrolladores front-end. Como resultado, en los últimos años, hemos tenido que ponernos al día con técnicas sofisticadas para construir aplicaciones de alta calidad, siendo una de las más esenciales las pruebas.

Cada vez más personas comenzaron a agregar pruebas a sus aplicaciones impulsadas por Vue.js. Con diferentes grados de éxito. El campo aún es relativamente nuevo y todos necesitamos más experiencia en cómo probar aplicaciones del lado del cliente de la manera más efectiva.

Con mi charla, quiero mostrar 1) cómo desarrollar una estrategia sólida de pruebas (herramientas y prácticas) y 2) trabajar en un ejemplo del mundo real de cómo combinamos las pruebas E2E con las pruebas de componentes.

Quiero resaltar algunos principios generales de la teoría de pruebas y luego pasar a la aplicación práctica, codificando en vivo de manera TDD.

33 min
12 May, 2023

Video Summary and Transcription

Esta charla discute la importancia de las pruebas y la necesidad de desacoplar las pruebas de los frameworks de pruebas, selectores CSS y interfaces de usuario. Se enfatizan los beneficios de escribir pruebas primero y se proporcionan ejemplos de simulación de listas de compras y trabajo de manera orientada a pruebas. La sección de preguntas y respuestas aborda temas como cambiar frameworks de pruebas, cobertura de errores y el uso de atributos de datos para el desacoplamiento.

Available in English

1. Introducción a las pruebas

Short description:

Hola, Londres. Hoy hablo sobre las pruebas. Hace un par de años, mi equipo y yo recibimos la tarea de trabajar en un proyecto completamente nuevo. Estábamos muy motivados y escribimos muchas pruebas. Sin embargo, yo era nuevo en las pruebas y cometí algunos errores. Las buenas pruebas nos permiten refactorizar el código con confianza, escribir un código mejor y más rápido, y desplegar en viernes si queremos. Para escribir buenas pruebas, necesitamos escribir primero las pruebas y desacoplar todas las cosas. Desacoplar las pruebas del marco de pruebas es importante para evitar reescribir las pruebas cuando el marco ya no se mantiene.

un proyecto completamente nuevo, por lo que pudimos comenzar un nuevo proyecto desde cero. Y esto es una buena noticia para nosotros, los desarrolladores, porque a la mayoría de nosotros nos gusta comenzar desde cero con nuevos proyectos. Y éramos un grupo de personas muy motivadas y queríamos hacer todo de la manera correcta. Y la manera correcta para nosotros también incluía escribir pruebas. Así que escribimos muchas. Escribimos muchas pruebas de extremo a extremo. Escribimos muchas pruebas de componentes y pasaron los años y todo resultó genial. Y, por supuesto, así no fue desafortunadamente. Entonces, ¿cuál fue el problema? El problema fue que, aunque escribimos muchas pruebas, yo, en ese momento, no sabía mucho sobre cómo escribir buenas pruebas. Así que era nuevo en este tema de las pruebas. y cometí algunos errores. Digamos que fue así. Entonces, muchas de esas promesas que vienen con los defensores de las pruebas no se cumplieron. Aún teníamos un gran desorden en el código al final. Pero, ¿cuáles son esas promesas que las buenas pruebas deberían permitirnos cumplir? Y la primera es que las buenas pruebas nos permiten refactorizar nuestro código con confianza. Y también, las buenas pruebas nos permiten escribir un código mejor y más rápido. Y las buenas pruebas nos permiten desplegar en viernes si queremos. Aún no tenemos que hacerlo. Entonces, mencioné la frase buenas pruebas un par de veces. ¿Y qué quiero decir con buenas pruebas? ¿Cómo escribimos buenas pruebas? Y la buena noticia es que solo hay dos cosas, dos cosas muy importantes que debes considerar. La primera es escribir primero las pruebas. Y la segunda es desacoplar todas las cosas. Comencemos con la segunda cosa, desacoplar todas las cosas. ¿Qué quiero decir con todas las cosas? Y hay tres aspectos en los que podemos desacoplar nuestras pruebas de nuestro código. El primero es desacoplar nuestras pruebas del marco de pruebas que estamos utilizando. Y ahora te preguntarás por qué deberíamos hacer esto. ¿Por qué deberíamos seguir el camino de desacoplar nuestras pruebas del marco de pruebas? ¿Cuál es el punto de hacerlo? Y la cosa es que imagina que estás utilizando, tienes cientos de pruebas y estás utilizando un tipo de marco de pruebas antiguo y los mantenedores del marco de pruebas deciden que ya no quieren mantener este marco. Y ahora de repente tienes que reescribir

2. Desacoplar las pruebas de los marcos de pruebas

Short description:

En el ecosistema de Vue, hay un nuevo y mejor marco de pruebas llamado V-Test que puede reemplazar a Jest. Desacoplar las pruebas del marco de pruebas permite cambiar fácilmente entre marcos. Podemos mejorar el desacoplamiento de las pruebas utilizando un controlador genérico e inyectándolo en el callback de la prueba. Esto nos permite cambiar entre diferentes marcos de pruebas cambiando solo un archivo. Para las pruebas de componentes, mover los métodos de prueba a archivos de utilidades separados permite intercambiar fácilmente los marcos de pruebas y personalizar las funciones de prueba.

cientos de pruebas y esto puede ser mucho trabajo. O hay un nuevo y mejor marco de pruebas disponible como ahora en el ecosistema de Vue o en general en el ecosistema tenemos V-Test que es muy popular en el ecosistema de Vue pero tiende a reemplazar a Jest tal vez. Y si desacoplas tu prueba del marco de pruebas, puedes cambiar de frameworks solo reescribiendo unas pocas líneas de código en lugar de todas tus pruebas. Entonces, ¿cuál es el problema y cómo podemos solucionarlo? Aquí podemos ver una prueba para una aplicación simple y porque estamos usando esta prueba para todas las demás, esta aplicación para todos los demás ejemplos también quiero mostrarte esta aplicación simple. Es una aplicación de lista de compras muy sencilla y podemos agregar algo como pan, por ejemplo, y luego tenemos pan en nuestra lista de compras y podemos agregar algo como leche y luego tenemos leche en nuestra lista de compras y al final también queremos poder eliminar esos elementos haciendo clic en ellos. Por ahora esto no funciona. Agregaremos esta función más tarde. Esta es la aplicación simple, la probamos y en esta prueba, esta prueba está acoplada al marco de pruebas. En este caso, Cypress por ejemplo. Entonces ves esto por este prefijo Cypress, Cy y estamos usando métodos de Cypress y estamos usando el método get para obtener algún selector y escribir algo en él y nuevamente usamos el método get de Cypress para hacer clic en algunos botones y así sucesivamente. Entonces, ¿cómo podemos mejorar esto? ¿Cómo podemos desacoplar esta prueba de Cypress? ¿Del marco de pruebas? Entonces podemos cambiar a playwright, por ejemplo, solo cambiando 1 archivo en lugar de cientos de pruebas. Y la solución puede verse así. Entonces aquí vemos que ahora inyectamos un controlador genérico en el callback de la prueba, implementación en un objeto de controlador genérico y para la prueba en sí no importa si este controlador es un controlador de playwright, un controlador de Cypress o incluso un controlador de V-Test, simplemente no importa. Y luego, en lugar del objeto Cypress, usamos el objeto del controlador que tiene una interfaz particular pero no importa qué implementación haya detrás. Nuevamente, tenemos este método get para obtener algunos selectores y hacer algunas cosas como hacer clic o escribir texto. Esto es para pruebas de extremo a extremo. De esta manera podemos desacoplar las pruebas de extremo a extremo. Ahora te preguntarás qué pasa con las pruebas de componentes. Y para las pruebas de componentes, creo que este aspecto no es tan importante porque para las pruebas de componentes estamos más cerca del código y tenemos que usar métodos específicos y tenemos que trabajar con variables de retorno y cosas así. Y implementar un controlador verdaderamente genérico para pruebas de componentes es más difícil de hacer, y creo que tampoco es tan importante. Pero lo que aún podemos hacer es mover todos los métodos de prueba que usamos en nuestras pruebas, como expect y mount por ejemplo, a nuestros propios archivos de utilidades. Y esto nos permite cambiar fácilmente los marcos de pruebas de prueba. Imagina que estabas usando Chess, por ejemplo, y ahora quieres cambiar a VTEST. Si tienes todos tus archivos o todos tus métodos en este archivo de utilidades, simplemente puedes cambiar este archivo de utilidades y todas tus pruebas seguirán funcionando. Y la segunda cosa que esto nos permite hacer es, por ejemplo, envolver la función mount. E imagina que tienes un UX Store o algo así o un enrutador, y puedes crear tu propia implementación personalizada de la función mount que siempre carga tu enrutador o tu tienda OpinIO y así sucesivamente. Esto es todo para el desacoplamiento de las pruebas de las pruebas de extremo a extremo y las pruebas de componentes. La siguiente forma en que podemos desacoplar nuestras pruebas del código en este caso es desacoplar nuestras pruebas de los detalles de implementación. Y tal vez ya hayas oído hablar de esto porque probablemente sea uno de los aspectos más importantes cuando se trata de desacoplar nuestras pruebas. Y veamos primero el problema

3. Desacoplar las pruebas de los selectores CSS

Short description:

Y aunque ahora está desacoplado del marco, todavía está acoplado a los detalles de implementación. Una de las formas más comunes en que las pruebas de extremo a extremo están acopladas a los detalles de implementación es a través de los selectores CSS. Podemos solucionar esto utilizando métodos de selección semánticos, como encontrar por texto de etiqueta, encontrar por rol y encontrar por texto. Estos métodos no solo desacoplan nuestras pruebas de los selectores CSS, sino que también garantizan un nivel básico de accesibilidad.

de nuevo. Así que vemos la prueba de antes. Y aunque ahora está desacoplado del marco, todavía está acoplado a los detalles de implementación. Y una de las formas más comunes en que las pruebas de extremo a extremo están acopladas a los detalles de implementación de nuestro código es acoplando las pruebas a los selectores CSS. Como en este caso, acoplamos esta prueba al selector CSS del campo de entrada del elemento. Y cada vez que algún desarrollador quiere cambiar el nombre del selector CSS o quiere cambiar o mover el selector CSS a otro lugar, la clase CSS, entonces esta prueba falla, aunque no debería fallar, porque la funcionalidad no falla. Y lo que nuestras pruebas deben hacer es asegurarse de que la funcionalidad funcione correctamente y no si algún selector CSS está en algún lugar y algún elemento. Así que esta prueba está acoplada a un detalle de implementación particular, los selectores CSS. ¿Y cómo podemos solucionar esto? Hay varias formas de solucionarlo, pero en mi opinión, la forma más o la mejor forma de solucionarlo es utilizando métodos de selección semánticos. Como en este caso, tenemos el método encontrar por texto de etiqueta. Y así podemos asegurarnos de que no solo no acoplamos nuestra prueba a los selectores CSS, es decir, a los detalles de implementación, sino también asegurarnos de que tenemos un nivel básico de accesibilidad garantizado, porque mediante este método encontrar por texto de etiqueta, nos aseguramos de que un campo de entrada tenga una etiqueta, lo cual debería tener para la accesibilidad. Así que nos aseguramos de que este campo tenga una etiqueta de título y luego escribimos algo en este campo de etiqueta de título. Otro método de selección semántico es encontrar por rol, que podemos usar para cosas en las que principalmente podemos hacer clic, en este caso, para un botón. Y de nuevo, no solo hemos desacoplado nuestra prueba de los selectores CSS, sino que también aseguramos un nivel básico de accesibilidad asegurándonos de que usemos un botón en lugar de un div o algo así. Así que aquí usamos encontrar por rol botón y luego seleccionamos el botón de agregar elemento y hacemos clic en él. Por último, pero no menos importante, tenemos este método encontrar por texto, donde podemos asegurarnos de que básicamente probamos nuestra aplicación a través de los ojos de nuestros usuarios, que no buscan algún selector CSS que ni siquiera ven, sino que buscan algún texto que esté en la pantalla o que no esté en la

4. Desacoplar las pruebas de la interfaz de usuario

Short description:

Para las pruebas de componentes, es importante desacoplarlas de los detalles de implementación. Podemos lograr esto escribiendo pruebas desde la perspectiva de un usuario real, utilizando la biblioteca de pruebas. Al simular interacciones de usuario y utilizar selectores semánticos, podemos desacoplar nuestras pruebas de componentes de los detalles de implementación y la interfaz de usuario.

Ahora, para las pruebas de componentes, esto es aún más importante. Para las pruebas de componentes, es muy importante desacoplarlas de los detalles de implementación. Y aquí, vemos una prueba de componente que está acoplada a los detalles de implementación de la peor manera posible, y ya lo vemos en la descripción, donde escribimos que debería emitir un evento de eliminación al ejecutar el método de eliminación. Entonces, el problema aquí es ejecutar el método de eliminación. Y lo vemos en la prueba también aquí ejecutamos directamente el método de eliminación en algún componente. Y esto es la peor forma de acoplar nuestras pruebas a los detalles de implementación, nuestras pruebas de componentes.

Entonces, ¿cómo podemos solucionar esto? Y nuevamente, podemos solucionarlo escribiendo nuestras pruebas más desde la perspectiva de un usuario real, cómo un usuario real usaría nuestra aplicación. Y lo que hago aquí es utilizar la maravillosa biblioteca de pruebas. Entonces, hay un paquete llamado biblioteca de pruebas. Y con eso, obtenemos esos selectores semánticos que vimos anteriormente y también algunos otros ayudantes como se puede ver aquí, la pantalla y el evento del usuario. Y luego cambiamos la descripción y decimos cuando se hace clic en el botón de eliminación en lugar de cuando se ejecuta un método. Entonces, es más a través de los ojos de un usuario, de un usuario real. Luego inicializamos un usuario con este método de evento de usuario que obtenemos del paquete de la biblioteca de pruebas. Y luego simulamos cómo un usuario real interactuaría con nuestro componente haciendo clic en él. Luego, nuevamente, usamos este método de selector semántico, encontramos un rol y sí, hacemos clic en este botón en este caso. Y de esa manera hemos desacoplado nuestra prueba de componente de los detalles de implementación también.

Bueno. Mucho para desacoplar de los detalles de implementación, lo cual es importante para tener pruebas que no o que nos permitan refactorizar nuestro código en lugar de ser un obstáculo. Porque si acoplamos nuestras pruebas a los detalles de implementación, no solo no son útiles, sino que incluso nos resulta imposible refactorizar nuestro código porque están acopladas al código. Y la última forma en que queremos desacoplar nuestras pruebas de, en este caso, la interfaz de usuario es, sí, desacoplar nuestras pruebas de la interfaz de usuario. Puede preguntarse, ¿cómo podemos desacoplar nuestras pruebas de la interfaz de usuario? ¿O qué quiero decir con desacoplar las pruebas de la interfaz de usuario? En un mundo perfecto, una prueba perfectamente desacoplada leería lo mismo. Y no importa para qué plataforma estemos escribiendo la aplicación, o para qué aplicación para qué plataforma estamos testing. Imaginemos que tenemos una aplicación Alexa controlada por voz. Espero no activar nada aquí. Tenemos una aplicación Alexa controlada por voz. Entonces, una prueba perfectamente desacoplada funcionaría para una aplicación controlada por voz de la misma manera que para una aplicación web, o para una aplicación móvil, o incluso para un cuaderno físico, si nos mantenemos en el dominio de una aplicación de lista de compras. Así que veamos un ejemplo. Aquí vemos la prueba de antes nuevamente, que ahora está desacoplada del marco, está desacoplada de los detalles de implementación, pero está acoplada a los detalles de la interfaz de usuario. Como, en este caso, confiamos en el hecho de que tenemos una URL. Y para aplicaciones controladas por voz, no tenemos una URL. Para aplicaciones móviles, no tenemos una URL.

5. Pruebas de aplicaciones controladas por voz

Short description:

Para aplicaciones web, confiamos en las URL, los campos de entrada y los botones, que son todos detalles de implementación de la interfaz de usuario. Para solucionar esto, podemos escribir un lenguaje específico del dominio para el dominio de la lista de compras. Este lenguaje nos permite realizar acciones como abrir la lista de compras y agregar elementos, independientemente del tipo de aplicación. El desacoplamiento de la interfaz de usuario es importante porque nos permite refactorizar fácilmente la interfaz de usuario. Podemos realizar cambios en la interfaz de usuario sin afectar las pruebas. Aquí hay un vistazo rápido de cómo podemos implementar esto creando un envoltorio alrededor de los métodos existentes.

Solo para aplicaciones web tenemos una URL. Por lo tanto, este es un detalle de implementación de la interfaz de usuario. También confiamos en el hecho de que tenemos campos de entrada. Para aplicaciones controladas por voz, no tenemos campos de entrada. Lo mismo ocurre con los botones. Estas son todas las formas en las que confiamos en la interfaz de usuario.

¿Y cómo podemos solucionar esto? Podemos solucionarlo escribiendo nuestro propio lenguaje específico del dominio. El dominio es el dominio de la lista de compras. Un lenguaje específico del dominio utiliza palabras comunes en este dominio. Por ejemplo, decimos que podemos abrir nuestra lista de compras. Y no importa si es una aplicación controlada por voz de Alexa, que debemos activar de alguna manera. O si es una aplicación móvil, o incluso si es un cuaderno físico, debemos abrirlo. Luego, agregar un elemento. Nuevamente, es el mismo concepto en todas partes. Puedes agregar un elemento mediante comandos de voz. Puedes agregar un elemento escribiéndolo en un cuaderno físico. Puedes agregar un elemento presionando un botón o escribiendo algo en un campo de entrada. Por último, esperamos que el elemento recién agregado aparezca de alguna manera en la lista o se guarde en la lista, lo cual no importa. Si lo escribimos de esta manera, no importa qué tipo de aplicación estemos probando.

Entonces, ¿por qué es importante hacer esto? ¿Por qué creo que esto es útil? No porque sea muy realista que escribamos la misma prueba para múltiples plataformas. Aunque, con un sistema como ese, incluso podríamos hacerlo. No creo que esa sea la parte más importante. Pero la parte más importante es que, de la misma manera que el desacoplamiento de los detalles de implementación nos permite refactorizar nuestro código, el desacoplamiento de la interfaz de usuario nos permite refactorizar nuestra interfaz de usuario. Por lo tanto, realmente podemos realizar cambios en la interfaz de usuario. Tal vez algún día tengamos un botón para activar alguna interacción, y al día siguiente queramos tener un comando de deslizamiento o algo así. Los detalles de la interfaz de usuario pueden cambiar en cualquier momento y por eso creo que es útil tener este desacoplamiento. Así que tengo que ser rápido, espero poder hacerlo. Aquí hay un vistazo rápido de cómo podemos implementar esto. Aquí vemos que es solo un envoltorio alrededor de los métodos que vimos anteriormente. Y sí, ahora puedes preguntarte, sí, pero si tenemos que cambiar, o si cambiamos nuestra interfaz de usuario, todavía tenemos que cambiar esas líneas.

6. Importancia de Escribir Pruebas Primero

Short description:

Pero el hecho importante es que podrías agregar elementos en docenas de pruebas. Y si cambias algo en la forma en que agregas elementos, solo necesitas cambiar esta línea en lugar de todas esas docenas de pruebas. El desacoplamiento del marco de pruebas, los detalles de implementación y la interfaz de usuario permite flexibilidad y facilidad de refactorización. Escribir pruebas primero, o pensar en las especificaciones, nos ayuda a considerar la API pública de nuestro código, lo que conduce a un mejor diseño y una retroalimentación más rápida. Permíteme mostrarte un ejemplo de cómo escribir pruebas antes de la implementación, específicamente para una función de eliminar elementos de una lista de compras.

Pero el hecho importante es que podrías agregar elementos en docenas de pruebas. Y si cambias algo en la forma en que agregas elementos, solo necesitas cambiar esta línea en lugar de todas esas docenas de pruebas.

Ok, así que esto fue todo sobre el desacoplamiento. Desacoplamiento del marco de pruebas. Así que podemos cambiar los marcos de pruebas o elegir el mejor marco para el trabajo, un marco muy rápido o un marco con una interfaz de usuario agradable. Luego, el desacoplamiento de los detalles de implementación, para que podamos refactorizar libremente nuestro código. Y por último, vimos el desacoplamiento de nuestras pruebas de la interfaz de usuario, para que podamos cambiar cosas en torno a la interfaz de usuario. Y tenemos este bonito lenguaje específico del dominio que se lee muy bien incluso para personas que no saben de programación, por ejemplo. Eso fue sobre el desacoplamiento de las pruebas de la interfaz de usuario.

Si quieres aprender más sobre pruebas visuales, asegurándote de que los cambios en tu código, por ejemplo, en tu CSS, no rompan cómo debería verse, te recomiendo ver la charla de Ramona el 15 de mayo sobre pruebas visuales.

Al principio te hablé de dos factores importantes, cómo podemos escribir buenas pruebas. Uno era el desacoplamiento de la implementación o el desacoplamiento en general. Y la segunda parte importante o la primera parte importante que te dije fue escribir pruebas primero. Y aquí ves que taché la palabra pruebas porque creo que es muy útil pensar en las especificaciones en lugar de pruebas. Porque si lo piensas, una prueba es algo que haces a un producto terminado. Entonces, si un producto sale de la línea de producción, por ejemplo, lo pruebas si funciona como se pretende. Pero las especificaciones, típicamente las escribes antes de producir algo. Especificas cómo debería funcionar antes de producir un fragmento de código o incluso un producto físico.

¿Por qué es esto importante? Escribir pruebas primero nos obliga a pensar en la API pública de nuestro código antes de implementarlo. Y por lo general, esto conduce a un mejor código. En segundo lugar, obtenemos una retroalimentación muy rápida. Si lo piensas, siempre pruebas tu código. Ya sea que lo hagas manualmente haciendo clic en tu aplicación, por ejemplo, o lo hagas automáticamente si ya tienes la especificación desde el principio. Luego, probar el código que acabas de escribir sucede automáticamente en un par de milisegundos, que es mucho más rápido de lo que puedes hacerlo manualmente. Y todo esto nos lleva a tener un mejor diseño.

Ahora podrías preguntarte cómo se ve esto en la práctica. ¿Cómo puedes escribir código o cómo puedes escribir pruebas antes de la implementación? Quiero mostrarte. Aquí vemos la prueba desde el final. Básicamente, ya está con el lenguaje específico del dominio. Ahora queremos una función para eliminar elementos haciendo clic en los elementos de la lista de compras. Así que debería ser posible eliminar elementos, así nomás.

7. Simulando Lista de Compras con Precondición

Short description:

Y para esto tenemos que simular que ya tenemos elementos en nuestra Lista de Compras y podemos hacer esto aquí con una precondición. Entonces, ahora ya hay elementos en nuestra Lista de Compras cuando comenzamos esta prueba, luego abrimos la Lista y en lugar de agregar un elemento, queremos eliminar un elemento. Queremos eliminar el elemento del pan y en lugar de esperar que esté en la lista, esperamos que el elemento no esté en la lista. A veces, funciona intentarlo de nuevo. La última prueba que acabamos de agregar no funciona porque el elemento todavía está en la lista, aunque ya no debería estar allí. También quiero agregar una prueba de componente como un paso intermedio para cumplir con las pruebas N20 más grandes. Ya preparé la prueba de componente aquí porque sé que tengo muy poco tiempo. Ya es hora de curador. Así que sí, lidiar con eso. Quiero mostrarte. Estoy terminando rápidamente. Me dice exactamente cuál es mi próximo paso. Me dice que no puede encontrar un elemento de botón porque no hay un elemento de botón.

Y para esto tenemos que simular que ya tenemos elementos en nuestra Lista de Compras y podemos hacer esto aquí con una precondición. Así que podemos ver, digamos, aquí, tiene elementos activos, por ejemplo. Entonces, ahora ya hay elementos en nuestra Lista de Compras cuando comenzamos esta prueba, luego abrimos la Lista y en lugar de agregar un elemento, queremos eliminar un elemento. Así que queremos eliminar el elemento del pan y en lugar de esperar que esté en la lista, esperamos que el elemento no esté en la lista. Ok.

Ahora podemos ejecutar esas pruebas y quiero ejecutarlas en Playwright, clásico. Sí. ¿Por qué no funciona esto? ¿Por qué no funciona esto? ¿Ya se están ejecutando? Intentémoslo de nuevo. Ok. A veces, funciona intentarlo de nuevo. Aquí vemos la maravillosa nueva interfaz de usuario de Playwright. Así que cuando Debbie no está en una conferencia, creo que tengo que hacer su parte y mostrarte lo increíble que es Playwright. Y aquí podemos ver que las dos primeras pruebas que ya teníamos tienen éxito. Pero la última prueba que acabamos de agregar no funciona porque el elemento todavía está en la lista, aunque ya no debería estar allí. Ok.

Entonces, ahora podríamos comenzar a escribir el código, pero quiero hacer más. Quiero agregar también una prueba de componente como un paso intermedio para cumplir con las pruebas N20 más grandes. Ya preparé la prueba de componente aquí porque sé que tengo muy poco tiempo. Ya es hora de curador. Así que sí, lidiar con eso. Quiero mostrarte. Estoy terminando rápidamente. Aquí tenemos la prueba de componente, es la misma que antes. Así que no entro en muchos detalles en este momento. Pero lo que quiero mostrarte es que ahora puedo ejecutarlas. Y ahora, me dice exactamente cuál es mi próximo paso. Porque me dice que no puede encontrar un elemento de botón porque no hay un elemento de botón. Así que vamos a nuestro código. Hagamos esto grande. Vamos a nuestra lista de compras y vemos que esto es una diferencia.

8. Trabajando de manera orientada a pruebas

Short description:

Cambiémoslo a un botón y guardemos. Ahora emite un evento. También tenemos que escuchar este evento en nuestro componente de la aplicación de lista de compras. Podemos trabajar de manera orientada a pruebas.

Por supuesto, no funciona. Cambiémoslo a un botón y guardemos. Y ahora nuestra prueba nos dice, sí, esta línea ahora funciona. Así que hemos tenido éxito en el primer paso. Pero no se emite ningún evento de eliminación. Así que cambiemos esto también. Y digamos, add click equals. Ahora tenemos que definir emits. Y definir emits así, espero. Hay un error tipográfico. Sí, tengo emits equals, definir emits así. ¿Puedes ver el error? Ah, gracias.

De acuerdo, ahora podemos decir emits y remove. Y ahora estamos un paso más adelante. Ahora hemos tenido éxito con eso, pero no emitimos un ID, así que también podemos cambiar esto. Y decir item ID. Y ahora este componente tiene éxito porque nuestro componente hace lo que se supone que debe hacer. Emite un evento, pero nuestra prueba de intención todavía falla porque ahora también tenemos que escuchar este evento en nuestro componente de la aplicación de lista de compras. Aquí tenemos el componente de lista de compras que acabamos de cambiar. Y aquí, ahora podemos escuchar el evento de eliminación. Y copiemos esta función de agregar elemento y digamos remove item. Aquí obtenemos un ID de elemento. Y tenemos, a través de nuestro repositorio, tenemos un método de actualización. Y este método de actualización toma un ID de elemento, y luego podemos actualizar el estado para que esté inactivo, creo. Y luego también actualizamos la lista. Ahora, podemos usar esto aquí. Podemos decir remove item, guardarlo, ir a nuestra prueba de extremo a extremo y ver que tiene éxito. Y también puedes ver aquí, funciona. De esta manera, podemos trabajar de manera orientada a pruebas. Gracias.

QnA

Q&A sobre Frameworks de Pruebas y Cobertura de Errores

Short description:

Así que escriban las pruebas primero, desacoplen todo y disfruten más de su trabajo. Estoy escribiendo un libro sobre todo esto. Si quieren echarle un vistazo, pueden ir allí y verlo. Comencemos con nuestra sesión. La primera pregunta, ¿por qué querría cambiar mi framework de pruebas? Por lo general, lo hacen porque el antiguo aún funciona, pero los nuevos desarrolladores quieren usar las nuevas y brillantes herramientas. También realizamos extracciones de bases de datos, por lo que no realizamos consultas SQL directamente en nuestro código. En nuestra aplicación web, los errores que tuvimos estaban en el procesamiento de datos del frontend. Si tienen problemas para cubrir esos errores con pruebas, intenten hacer más desarrollo orientado a pruebas.

Así que escriban las pruebas primero, desacoplen todo y disfruten más de su trabajo. Y por cierto, estoy escribiendo un libro sobre todo esto. Así que si quieren echarle un vistazo, pueden ir allí y verlo.

Entonces, Marcus, muchas gracias por esto. No estoy seguro si querías mostrarnos un poco más. Siéntete libre de unirte a nuestra sesión de preguntas y respuestas, pero al menos ejecuta Playwright. Eso es lo mejor cuando solo tienes un problema, no cambias nada, lo ejecutas nuevamente y funciona. Sí, creo que eso es correcto.

De acuerdo, comencemos con nuestra sesión. La primera pregunta, que no es una pregunta, mantengámonos en silencio en la parte de atrás para que las personas puedan enfocarse realmente en las charlas. De acuerdo, así que sean un poco más silenciosos. Pregunta relacionada, ¿por qué querría cambiar mi framework de testing? Desarrollador terco. Sí, esa es una buena pregunta. Por lo general, probablemente no lo hagas con tanta frecuencia, pero lo veo de dos maneras. En primer lugar, a veces lo haces porque ahora, por ejemplo, ves que Jest, el desarrollo de Jest, por ejemplo, se está desacelerando, y también hay... Por ejemplo, en mi trabajo, estamos usando Nightwatch Jest. Tal vez ni siquiera hayas oído hablar de eso porque ya no es realmente lo más nuevo, lo más de moda en este momento, así que hay muchos casos en los que creo que tienes o quieres cambiar los frameworks de pruebas porque aunque tal vez el antiguo aún funcione, pero los nuevos desarrolladores quieren usar las nuevas y brillantes herramientas. Quieren usar Playwright en lugar de estas herramientas antiguas. Así que creo que sucede bastante a menudo, y la segunda forma en que quiero pensar en esto es que también realizamos extracciones de bases de datos, por lo que no realizamos consultas SQL directamente en nuestro código porque no es tan frecuente que realmente cambiemos nuestra base de datos. Probablemente sea lo último que cambiemos, pero sigue siendo una buena práctica porque también nos permite ser más flexibles con nuestro código. Tiene total sentido. Una vez quise cambiar de JESs a VTests y simplemente no lo hice porque todo estaba demasiado acoplado.

La siguiente pregunta. En nuestra aplicación web, los errores que tuvimos fueron realmente difíciles de cubrir con pruebas. No tuvimos errores con la interfaz de usuario. Nuestros errores estaban en el procesamiento de datos del frontend. ¿Estos no son un buen caso de uso para las pruebas, o nos faltó algo? Sospecharía que no escribieron las pruebas primero porque eso es una señal típica. Ese también fue un gran problema con la aplicación que escribimos, que les mencioné al principio, es que nuestra estructura de datos era muy complicada. Teníamos mucho estado global, lo que hacía que toda nuestra aplicación fuera muy difícil de probar. Si tienen problemas para cubrir esos errores con pruebas, entonces probablemente deberían intentar hacer más pruebas primero, más desarrollo orientado a pruebas, y luego podrían ver los patrones que hacen que los componentes sean difíciles de probar.

Usando Atributos de Datos para Desacoplar

Short description:

Usar atributos de datos adicionales en lugar de selectores CSS es una forma de desacoplar las pruebas de los detalles de implementación. Si bien fue un método favorito durante mucho tiempo, el uso de métodos de selección semánticos proporciona una forma más agradable y efectiva de desacoplar las pruebas. Sin embargo, el uso de atributos de datos sigue siendo una buena práctica y una forma sencilla de comenzar.

Y luego podrían refactorizar y tener más pruebas que sean realmente útiles. De acuerdo, gracias Marcus. La siguiente pregunta es ¿qué opinas sobre el uso de data atributos adicionales en lugar de selectores CSS? Sí, esa es una posible forma en la que puedes desacoplar tus pruebas de los detalles de implementación utilizando atributos data QA o data minus test. También es una buena forma de hacerlo. Fue mi forma favorita de hacerlo durante mucho tiempo, pero luego dejé de hacerlo porque siento que los métodos semánticos, los métodos de selección que les mostré, hacen que sea mucho más agradable leer tus pruebas y son incluso una mejor forma de desacoplar la prueba. Pero definitivamente es una buena práctica utilizar esos atributos data también. No hay nada de malo en ello. Sí. Bastante rápido para comenzar y bastante simple. Nuestra próxima pregunta es, agregas un controlador para desacoplar el framework de pruebas, pero aún depende de la API, ¿verdad? De alguna manera. Entonces, la forma más fácil de comenzar con un controlador es tener la misma API que tienes con la herramienta que estás usando actualmente, por ejemplo. Pero lo que tiendo a hacer es hacer mi propia API. A menudo tiene sentido. Tienes algunas cosas complicadas que debes hacer en tu aplicación, como un componente de selección personalizado complicado, por ejemplo, que no es tan fácil de hacer o interactuar con él. Entonces puedes escribir tu propio comentario para hacer cosas como esa. Lo que tiendo a hacer es no tener una correspondencia uno a uno con PlayWrite o cualquier otro framework de pruebas que use primero, sino usar una API que tenga sentido para mí, que a veces es la misma que PlayWrite, por ejemplo, y a veces no. De acuerdo, muchas gracias. La siguiente pregunta es, si heredas código no probado, ¿por dónde empezarías para mejorar la cobertura? Sí, esa es la gran pregunta, ¿verdad? Porque muchos de nosotros nos encontramos en esta situación. Sí, no es una respuesta fácil, no es una gran respuesta para esto. La mejor respuesta que puedo dar es que siempre que toques algo, agregues pruebas para lo que ... para la nueva función que agregas, o si cambias una función, agrega una prueba para la función que cambias. Por lo general, esas grandes refactorizaciones no funcionan muy bien, o no obtienes la aprobación de algún gerente o algo así. Entonces, creo que la mejor manera, la mejor ruta que puedes seguir es siempre agregar pruebas para en lo que estás trabajando actualmente. Y con suerte, en algún momento tendrás cobertura para todos esos lugares donde haces muchos cambios, y todos esos lugares de código donde haces muy pocos cambios no importan tanto de todos modos. Creo que podrías escribir un libro solo sobre esta pregunta. Sí, probablemente. Y la última para esta sesión es, ¿recomiendas simular data cuando necesitas probar un componente que llama a una API? Sí, por lo general no debes simular mucho, pero la gran excepción son las solicitudes de API externas, pero el enfoque está en lo externo. Entonces, si tienes un BFF, por ejemplo, entonces creo que deberías intentar al menos en tus pruebas de extremo a extremo no simular esas solicitudes. Para las pruebas de componentes, tiendo a simular todas las solicitudes, pero lo que recomiendo es que tengas un lugar donde coloques esas solicitudes externas. Lo que quiero decir con eso es que tengas un tipo especial de componente en tu aplicación donde coloques efectos secundarios como solicitudes externas y cosas así. Y esos podrían ser componentes de página, por ejemplo. Entonces, creo que es una buena práctica colocar todas tus consultas de database, todas tus consultas de API, en componentes de página o algo así, o también puedes llamarlos componentes de vista, porque básicamente es el lugar donde acoplas tu aplicación a partes externas. Pero todos los demás componentes no están acoplados a nada externo y, por lo tanto, son mucho más fáciles de probar. De acuerdo. Muchas gracias, Markus. Quedan muchas preguntas. Como dije, a los desarrolladores nos encantan las pruebas. Así que siéntanse libres de subir y hacer preguntas adicionales. Y por ahora, eso es todo. ¡Hagan algo de ruido!

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

Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
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 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
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
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.