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.
This talk has been presented at Vue.js London 2023, check out the latest edition of this JavaScript Conference.
FAQ
Desacoplar las pruebas del marco de pruebas es crucial porque permite cambiar de un marco a otro con facilidad, evitando la necesidad de reescribir todas las pruebas si el marco actual deja de ser mantenido o si aparece una mejor opción.
Las pruebas se pueden desacoplar de los detalles de implementación utilizando métodos de selección semánticos, como buscar por texto de etiqueta o por rol, lo que además ayuda a asegurar la accesibilidad y reduce la dependencia de los selectores CSS específicos.
Las buenas pruebas permiten refactorizar el código con confianza, escribir código de mejor calidad más rápidamente y desplegar cambios incluso en momentos críticos sin temor a errores, como antes de un fin de semana.
Los dos aspectos cruciales son escribir las pruebas primero antes de desarrollar el código y desacoplar las pruebas tanto del marco de pruebas como de los detalles específicos del código y la interfaz de usuario.
El acoplamiento de pruebas a la interfaz de usuario puede limitar la flexibilidad del software para adaptarse a diferentes plataformas o cambios en la interfacción del usuario, como pasar de clics a comandos de voz.
Se recomienda agregar pruebas cada vez que se modifique el código heredado, especialmente al añadir nuevas funcionalidades o al modificar las existentes, asegurando así gradualmente una mejor cobertura de pruebas.
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.
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!
Vue 3 has seen significant adoption and improvements in performance, bundle size, architecture, and TypeScript integration. The ecosystem around Vue 3 is catching up, with new tools and frameworks being developed. The Vue.js.org documentation is undergoing a complete overhaul. PNIA is emerging as the go-to state management solution for Vue 3. The options API and composition API are both viable options in Vue 3, with the choice depending on factors such as complexity and familiarity with TypeScript. Vue 3 continues to support CDN installation and is recommended for new projects.
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.
The Talk discusses the recent feature updates in Vue 3.3, focusing on script setup and TypeScript support. It covers improvements in defining props using imported types and complex types support. The introduction of generic components and reworked signatures for defined components provides more flexibility and better type support. Other features include automatic inference of runtime props, improved define emits and defined slots, and experimental features like reactive props destructure and define model. The Talk also mentions future plans for Vue, including stabilizing suspense and enhancing computer invalidations.
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
2 authors
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.
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.
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.
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
Vue3 fue lanzado a mediados de 2020. Además de muchas mejoras y optimizaciones, la principal característica que trae Vue3 es la API de Composición, una nueva forma de escribir y reutilizar código reactivo. Aprendamos más sobre cómo usar la API de Composición de manera eficiente.
Además de las características principales de Vue3, explicaremos ejemplos de cómo usar bibliotecas populares con Vue3.
Tabla de contenidos: - Introducción a Vue3 - API de Composición - Bibliotecas principales - Ecosistema Vue3
Requisitos previos: IDE de elección (Inellij o VSC) instalado Nodejs + NPM
La web ha evolucionado. Finalmente, también lo ha hecho el testing. Cypress es una herramienta de testing moderna que responde a las necesidades de testing de las aplicaciones web modernas. Ha ganado mucha popularidad en los últimos años, obteniendo reconocimiento a nivel mundial. Si has estado esperando aprender Cypress, ¡no esperes más! Filip Hric te guiará a través de los primeros pasos sobre cómo empezar a usar Cypress y configurar tu propio proyecto. La buena noticia es que aprender Cypress es increíblemente fácil. Escribirás tu primer test en poco tiempo y luego descubrirás cómo escribir un test de extremo a extremo completo para una aplicación web moderna. Aprenderás conceptos fundamentales como la capacidad de reintentar. Descubre cómo trabajar e interactuar con tu aplicación y aprende cómo combinar pruebas de API y de UI. A lo largo de todo este masterclass, escribiremos código y realizaremos ejercicios prácticos. Saldrás con una experiencia práctica que podrás aplicar a tu propio proyecto.
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
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.
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
Comments