CCTDD: Diseño impulsado por pruebas de componentes Cypress

Rate this content
Bookmark

La primera parte de la charla se centrará en una variedad de patrones al usar las pruebas de componentes Cypress y TDD para crear componentes de React. Los ejemplos de código serán de la aplicación Angular's Tour of Heroes para que el contenido sea relevante para una comunidad más amplia. Actualmente estoy trabajando en un GitBook reescribiéndolo en React usando pruebas de componentes Cypress, así que debería haber mucho contenido para destilar en la charla.

La segunda parte de la charla se centrará en estrategias de pruebas, tipos de pruebas y dónde aplicarlas, y finalmente compararlas y contrastarlas con los enfoques familiares de la industria.

Terminaremos con conclusiones clave, repositorios de aplicaciones de muestra para ayudar con el aprendizaje y estrategias de implementación.

25 min
03 Nov, 2022

Video Summary and Transcription

El diseño impulsado por pruebas de componentes Cypress puede llevar a los ingenieros de front-end al siguiente nivel al cubrir ejemplos de TDD, pruebas de componentes, pruebas de punto final y las mejores prácticas recomendadas. El flujo de TDD implica comenzar con pruebas fallidas, hacer que funcionen y luego mejorarlas. Las pruebas de componentes se pueden escribir de forma incremental, utilizando envoltorios y props personalizados. Las diferencias entre React Testing Library y Cypress Component Test radican en el estilo de la API. Se puede lograr la cobertura de código con pruebas de componentes Cypress, y se puede utilizar el adaptador Pack.js Cypress para evitar la duplicación de pruebas entre el backend y el frontend.

Available in English

1. Introducción a Cypress Component TDD

Short description:

Hola, soy Burat, un ingeniero de personal y arquitecto de pruebas en Xtent. El diseño impulsado por pruebas de componentes de Cypress puede llevar a nuestro ingeniero de front-end al siguiente nivel. Cubriremos ejemplos de TDD, pruebas de componentes, pruebas de punto final y las mejores prácticas recomendadas. La aplicación bajo prueba es una versión de React de dos reseñas de Angular. Tenemos una aplicación de React con un servidor JSON y muchos ejemplos de pruebas de componentes de Cypress. Comenzaremos con una prueba de marcador de posición, aseguraremos la representación y los estilos, y luego escribiremos una prueba fallida para un atributo de enlace.

Mi nombre es Burat. Soy un ingeniero de personal y arquitecto de pruebas en Xtent. Y creo que el diseño impulsado por pruebas de componentes de Cypress puede llevar a nuestro ingeniero de front-end al siguiente nivel.

Hablaremos sobre un ejemplo de TDD y pasaremos por nuestra prueba de componentes. Hablaremos más sobre las pruebas de componentes. Cubriremos las pruebas de punto final dentro del contexto de TDD. Y finalmente, concluiremos con las mejores prácticas recomendadas.

La aplicación en la prueba son dos reseñas de Angular. Todos ustedes están familiarizados con ella. Está reescrita en React. Y el libro, Cypress component test-driven design. Podrán encontrar el enlace al libro aquí mismo. Y la aplicación final con todo el código fuente, todo en esta presentación en este enlace.

Es una aplicación de React con un servidor JSON, algunas herramientas agradables. Tenemos muchos ejemplos de pruebas de componentes de Cypress aquí. Cada uno de ellos tiene un espejo de la biblioteca de pruebas de React. Tienes pruebas de integración de UI, simulación de la red. Tienes pruebas de extremo a extremo de API y de UI. La proporción de ellas es de uno a cinco a 15, lo que te da una idea sobre la arquitectura de las pruebas.

Aquí está nuestro primer componente. Lo encontrarás en el Capítulo 3 del libro, nuestro código final aquí mismo en este enlace. Comienza con una prueba de marcador de posición. Primero, quieres asegurarte de que puedas renderizar algo, importaste el archivo correcto, tienes los estilos. Este es un buen punto de partida de referencia. Puedes copiar y pegar esto en cada ejecución de prueba de componente de inicio. Así que tienes eso siendo renderizado. Genial. Escribe una prueba fallida porque con TDD, tienes pruebas de detección de fallos para cosas que importan. Así que queremos que un enlace tenga un atributo que vaya a reactjs.org.

2. Diseño y Mejoras de Pruebas de Componentes

Short description:

Tenemos nuestro primer fallo. Intentamos hacerlo funcionar agregando un enlace con un href. Las pruebas de componentes pueden ayudar en los ciclos de refactorización rojo-verde. Agregamos una prueba fallida para asegurar la visibilidad y luego agregamos un icono para una mejor representación.

Y tenemos nuestro primer fallo. Genial, una pequeña prueba, fallando, y tratamos de hacer que funcione, agregando un enlace con un href. Una vez que eso fue algo que fallaba, quieres hacer lo mínimo para que funcione, y luego simplemente quieres intentar mejorarlo. Quieres usar las pruebas de componentes como herramienta de diseño para ayudar en tus ciclos de refactorización rojo-verde.

No estamos viendo nada que se esté representando, así que pensamos, bueno, aquí hay una idea, asegurémonos de que esto sea visible. Así que agregamos una prueba fallida, ahora tenemos un rojo. Las mejoras incrementales de visión significan que puedes usar la retroalimentación visual que no cumple tus expectativas como indicador rojo. No lo estoy viendo, quiero algo ahí. Voy a agregar un icono para ver una representación decente. Que algo sea visible realmente no ayuda, pero quiero ver lo correcto.

3. Escribiendo Pruebas Incrementales y Envoltorios Personalizados

Short description:

Lo obvio pero difícil de hacer con TDD es escribir pruebas incrementales muy pequeñas a la vez. Quieres construir el componente de forma iterativa utilizando pruebas. Al final, pensamos: 'ok, tal vez necesitemos un icono haciendo este componente'. Si tienes TypeScript y ESLint, tienen herramientas que también pueden ayudar en tus ciclos de refactorización rojo-verde. Pero podemos simplemente agregar ese atributo justo ahí. Para que la prueba funcione, además de eso, tenemos que envolverlo con 'browser-router' porque así es como montas tu componente cuando usas 'react-router-dump', simplemente lo envuelves con 'browser-router'. Siempre debes recordar que una prueba de componente es una aplicación a pequeña escala. No hay problema, puedes escribir una función de envoltorio personalizada. Volviendo a la prueba, quieres agregar un enlace que tenga tres spans con algunas cadenas. Entonces, escribe una prueba fallida para eso.

Lo obvio pero difícil de hacer con TDD es escribir pruebas incrementales muy pequeñas a la vez. Quieres construir el componente de forma iterativa utilizando pruebas. Quieres obtener más información al respecto con la prueba, como si estuvieras improvisando, pero a medida que improvisas, avanzas y agregas un paso.

Entonces tenemos un atributo, agregamos una prueba para ello y luego agregamos esa comprobación de atributo. Escribimos otro paso de prueba y luego agregamos otro atributo para que funcione. Al final, pensamos: 'ok, tal vez necesitemos un icono haciendo este componente'. Agregamos ese selector de tamaño de datos a la etiqueta superior del componente, lo cual recomiendo porque hace que el componente sea muy fácil de encontrar cuando se usa como hijo o en pruebas de extremo a extremo. Así que hacemos eso, y luego debajo de ese componente, esperamos que se renderice un '.sdg' porque ese es el icono que estamos buscando.

Si tienes TypeScript y ESLint, tienen herramientas que también pueden ayudar en tus ciclos de refactorización rojo-verde. Aquí, falta la propiedad 2. NavLink es de 'react-router-dump'. Así que realmente no tenemos que tener una prueba fallida para ello. Pero podemos simplemente agregar ese atributo justo ahí. Para que la prueba funcione, además de eso, tenemos que envolverlo con 'browser-router' porque así es como montas tu componente cuando usas 'react-router-dump', simplemente lo envuelves con 'browser-router'. Siempre debes recordar que una prueba de componente es una aplicación a pequeña escala. Así que debes replicar los envoltorios de tu aplicación. Estás usando 'browser-router' en la aplicación principal. Y usarás 'browser-router' cada vez que montes tu componente.

Pero tu aplicación puede verse así. Y tus montajes de prueba se verán como el de la izquierda. No hay problema, puedes escribir una función de envoltorio personalizada. Podrás encontrar el enlace aquí y también lo escribirás en el libro. Y es solo algo que haces una vez. Si algunos de tus componentes no necesitan ser envueltos con algunos de estos, está perfectamente bien. Los envoltorios adicionales no cambian realmente cómo se comporta el componente. El componente simplemente usa lo que necesita. Es exactamente lo mismo que harías con la biblioteca de pruebas de React. También puedes escribir diferentes tipos de envoltorios personalizados, ¿verdad? Algunos envoltorios para estos componentes, pero un envoltorio diferente para otro conjunto de componentes. Volviendo a la prueba, quieres agregar un enlace que tenga tres spans con algunas cadenas. Entonces, escribe una prueba fallida para eso.

4. Fallo de Prueba y Comparación de Diseño de Prueba

Short description:

Nos encontramos con un fallo debido a la falta de un selector de datos de enlace de navegación, que luego se agrega junto con clases para mejorar el renderizado. La prueba pasa y se renderiza como se espera. Surge la pregunta: ¿deberían descomponerse las pruebas o mantenerse como un flujo único? El lado derecho, con un flujo único, es preferible si el estado inicial es común. Sin embargo, siempre que las pruebas no se dupliquen y sean independientes del orden y sin estado, ambos enfoques son aceptables. Se realiza una comparación con la biblioteca de pruebas de React, donde la intención sigue siendo la misma pero el estilo de API difiere.

Y luego obtenemos nuestro fallo. Porque ni siquiera tenemos ese selector de datos de enlace de navegación. Así que procedemos a agregar eso. Agregamos algunas clases para que el renderizado se vea bien. Ahí están nuestros spans. Cada uno de ellos tiene un texto codificado en duro. Y tenemos una prueba que pasa al final. Se renderiza como queremos.

Surge la pregunta, ¿debemos descomponer las pruebas o no? En el lado izquierdo y derecho, es la misma prueba exacta y lo mismo. El lado izquierdo lo descompone, el lado derecho solo realiza un flujo. Lo que importa es el estado inicial de una prueba. Si alcanzar este estado es común, entonces, en mi opinión, el lado derecho, una oportunidad para una mejora de la prueba es más fuerte. Prefiero el ejemplo de la derecha. Siempre que las pruebas no se dupliquen, sean independientes del orden y sin estado, ambos lados están bien. La razón por la que los probadores de unidades pueden preferir el lado izquierdo es porque quieren tener un radio de explosión más pequeño. Esto no es un problema. Si tienes un ejecutor de pruebas de Cypress, es muy fácil encontrar exactamente dónde ocurrió el fallo. Solo tienes que tener cuidado de no hacer lo del lado izquierdo.

Entonces aquí tenemos tres bloques de borde, se superponen entre sí. Entonces, el primero está cubierto en el segundo y el tercero cubre el segundo. Así que esto es solo una prueba. Podemos escribir solo una prueba, la mayoría del tercer bloque en la comprobación de visibilidad desde la primera prueba, y eso es suficiente. Un ejemplo de lo que no hacer y qué hacer. Aquí está la comparación con la biblioteca de pruebas de React. Uno a uno, es lo mismo. Puedes traducir cada línea. La intención siempre es la misma. La diferencia está en el estilo de la API. Así que tienes Async, Await, Asignaciones de Variables en un lado, y tienes una sintaxis encadenada, un poco más de flujo en el lado derecho. Pero la intención, tus acciones, lo que sea que estés haciendo es lo mismo.

5. Pruebas de Componentes con Props y Wrappers

Short description:

Solo diferentes formas de hacerlo. Tendremos un segundo ejemplo y más puntos sobre las pruebas de componentes, especialmente sobre props, wrappers de componentes y relaciones padre-hijo. Puedes manipular tu componente tanto con props como con wrappers. Puedes pasar datos con props, ya sea agregando una prop al componente o usando un wrapper. Al agregar props, añades la propiedad a los tipos de componente, la agregas a los argumentos del componente y la usas en el componente. Esta vez, estamos agregando la propiedad 'value' y una prueba que falla para ello. También escribimos una prueba que falla para que un formulario sea de solo lectura y agregamos la prop en consecuencia. Cuando te encuentres con fallos, es preferible añadir más pruebas o refactorizar en lugar de añadir código fuente adicional.

Solo diferentes formas de hacerlo. Así que eso fue un recorrido de ejemplo de TDD con pruebas de componentes. Ahora tendremos un segundo ejemplo y algunos puntos más sobre las pruebas de componentes, especialmente sobre props, wrappers de componentes y relaciones padre-hijo.

Este ejemplo es del capítulo cinco del libro, y aquí está el código final. Puedes usar codificación en duro inicialmente, o puedes usar console log para que tu prueba pase. Solo codificación en duro, todo está bien ahí. Luego manipulas tu componente ya sea con props o wrappers.

Aquí tenemos una prop. En lugar de una prueba codificada en duro, agregamos esa prop aquí mismo, el placeholder. Y luego lo agregamos al componente. Puedes pasar datos con props. Como aquí, tenemos una prop para 'heroes', pasamos un array vacío. Y luego aquí, pasamos un array de héroes. En el lado derecho, en la parte superior, no estamos pasando nada, solo el componente por sí mismo. Pero si quisieras, podrías tener un wrapper allí, por ejemplo, Context API, y así proporcionar un valor allí, el array de villanos. Y así es como manipulamos nuestros componentes. Así que puedes usar una propiedad o un wrapper. Así es como personalizas las pruebas de tus componentes en Cypress, React y cualquier otro lugar. Al agregar props, agregas la propiedad, aquí estamos agregando la propiedad 'name', y luego agregas la prop a los tipos de componente. Lo agregas a los argumentos del componente, luego lo usas en el componente. Mismo flujo, lo recorreremos. Esta vez estamos agregando la propiedad 'value', ¿una prueba que falla con eso, ¿verdad? Y luego agregamos la prop, el argumento, y lo usamos en la prueba misma, que está en el componente. Y tenemos un buen renderizado en algún momento, que usaremos para un formulario. Queremos que este formulario también tenga la capacidad de ser de solo lectura. Así que escribimos una prueba que falla para eso, y luego agregamos la prop. Y si tenemos eventos, simplemente los iniciamos. Aquí tenemos un evento que son dos pulsaciones de tecla, así que queremos que el evento de cambio se llame dos veces. Primero, las pruebas que fallan, y luego agregamos la prop, los argumentos, y nuevamente, lo usamos en el componente. Cuando veo fallos a través de las pruebas, y cuando tienes pruebas verdes, es mejor añadir más pruebas o refactorizar en lugar de añadir código fuente adicional. Esto es muy importante.

6. Diseño de Pruebas y Ejemplo de Relación Padre-Hijo

Short description:

A veces tenemos una prueba que pasa y luego agregamos mucho código fuente, no es necesario hacer eso. Un poco de prueba, hacerla funcionar, mejorarla. Aquí hay un ejemplo de relación padre-hijo. Siempre verifica si estás duplicando el esfuerzo de prueba que ya se ha cubierto en otro lugar. Queremos encontrar oportunidades para cubrir diferentes funcionalidades. Con JSX y literales de plantilla, puedes ser bastante creativo con tus selectores.

A veces tenemos una prueba que pasa y luego agregamos mucho código fuente, no es necesario hacer eso. Un poco de prueba, hacerla funcionar, mejorarla. Si tienes algo que funciona, es mejor agregar más pruebas, quieres tener un fallo primero o refactorizar antes de ir al código fuente.

Aquí hay un ejemplo de relación padre-hijo. Entonces, este es un hijo que se utiliza en el padre, dos variedades diferentes, un nombre y una descripción. Siempre verifica si estás duplicando el esfuerzo de prueba que ya se ha cubierto en otro lugar. Queremos encontrar oportunidades para cubrir diferentes funcionalidades. A la derecha, ya tenemos una verificación de que estamos escribiendo algo y luego eso es visible. Estamos duplicando esa prueba aquí en el padre, y eso no es bueno. En el padre, puedes hacer algo más. Podemos verificar que el padre renderiza dos variantes del hijo. Aquí hay otro consejo, con JSX y literales de plantilla, puedes ser bastante creativo con tus selectores. Me gusta tener un conjunto de datos en la etiqueta superior del componente, y si hay alguna variante, simplemente exploto JSX y literales de plantilla, y es bastante divertido.

7. React Testing Library vs Cypress Component Test

Short description:

React Testing Library versus Cypress Component Test. La principal diferencia está en cómo se realiza la prueba del evento onChange. Las pruebas de punto final son excelentes cuando has terminado de construir tus componentes. Quieres ayudar a la prueba al nivel más bajo y luego avanzar cuando no puedas probar con confianza. Este es un ejemplo de eso. Cómo hacer una función con ejemplos de TDD. Siempre quieres recordar lo que estás haciendo en tus componentes secundarios. El flujo de TDD es exactamente el mismo con E3. Comienzas con algo que falla, haces lo mínimo para que funcione y luego, si puedes mejorarlo, haces refactorización. Una vez que las cosas funcionan, es mejor agregar más fallos.

React Testing Library versus Cypress Component Test. La principal diferencia está en cómo se realiza la prueba del evento onChange. En el lado derecho está CyGet, la etiqueta de cambio aquí, y luego verificamos la cantidad de llamadas, y en el lado izquierdo, suggest-fn, en lugar de un sitio stub, y verificamos que se haya llamado tantas veces. Haciendo exactamente lo mismo, cada paso se traduce en un estilo ligeramente diferente.

Recorrimos un ejemplo de TDD, un ejemplo de componente, dos ejemplos de prueba de componente, algunas mejores prácticas allí. Ahora veamos TDD con pruebas de punto final. Las pruebas de punto final son excelentes cuando has terminado de construir tus componentes. Ahora es el momento de enrutamiento, gestión de estado, flujos de aplicación, componentes que se comunican entre sí o con el backend. Ahí es donde entra en juego E3. Pero recuerda, quieres ayudar a la prueba al nivel más bajo y luego avanzar cuando no puedas probar con confianza. Este es un ejemplo de eso. No puedo hacer nada acerca del enrutamiento cuando estoy trabajando con componentes. Necesito una prueba de punto final. Primero, miras al hijo. ¿Puedo hacer esto en el hijo? No, y pasas al padre. Si eso no es suficiente, tienes una prueba de integración de UI, falsificas la red, pero tus componentes se comunican entre sí y tal vez necesites el backend. Tal vez puedas usar pruebas de punto final en ese caso.

Cómo hacer una función con ejemplos de TDD. Esta es una prueba de punto final. Estamos usando TDD. Es del capítulo 13 y es el código final de esta prueba. Siempre quieres recordar lo que estás haciendo en tus componentes secundarios. Aquí estamos visitando el componente, estamos visitando la aplicación y una prueba de punto final, y nos aseguramos de que se muestre el componente de la barra de encabezado. ¿Cómo modificamos nuestra aplicación para que se muestre el componente de la barra de encabezado? Vamos y echamos un vistazo al hijo, la barra de encabezado, y allí estamos usando el enrutador del navegador y envolviendo la barra de encabezado, por lo que nuestra aplicación también tendrá que hacer eso. Puedes hacer trampa y siempre mirar la prueba de componente que ya construiste. Te facilitarán la vida cuando estés escribiendo tu prueba de punto final o cuando estés escribiendo otras pruebas de componente. Ya tendrás los selectores allí, los selectores de tamaño de datos, y siempre puedes consultarlos, es documentación para ti, ¿qué hago con esto? El flujo de TDD es exactamente el mismo con E3. Quieres comenzar con algo que falle, hacer lo mínimo para que funcione, por lo que es mínimo en el componente de la barra de navegación, y luego, si puedes mejorarlo, hacer refactorización. Una vez que las cosas funcionan, es mejor agregar más fallos.

8. Not Found Route and Best Practices

Short description:

Quieres tener una ruta no encontrada y mostrar un componente de no encontrado. Agrega una prueba que falle, luego agrega el componente de no encontrado y configura la ruta. Busca fallos y continúa agregando pruebas hasta que haya un fallo. En un ejemplo de TDD utilizando pruebas de extremo a extremo para el enrutamiento, visita la ruta del héroe y asegúrate de que se muestre el componente del héroe. Sigue las mejores prácticas recomendadas para las pruebas de extremo a extremo de la API, como usar un cliente de prueba de API en lugar de un cliente de UI, estar al tanto de los conjuntos de pruebas, evitar la duplicación y utilizar cantidades moderadas de pruebas de extremo a extremo.

No encontrada Ruta y Mejores Prácticas

Quieres tener una ruta no encontrada, ¿verdad? Y eso debería mostrar un componente de no encontrado, ¿verdad? Primero la prueba que falla, y luego agregamos ese componente de no encontrado, hacemos la configuración de la ruta y estamos descubriendo más sobre la aplicación a través de las pruebas de esta manera. Si tenemos pruebas que pasan, queremos agregar pruebas o refactorizar antes de agregar más código fuente.

Tenemos una prueba que pasa. Agregamos esa verificación adicional para la ubicación, todavía estamos en verde. Entonces, bien, luego podemos pensar en otro fallo. Queremos buscar estos fallos. Los fallos son geniales cuando estás haciendo TDD. Quieres seguir agregando pruebas hasta que haya un fallo. Eso es muy bueno. Una vez que tenemos esa prueba que falla, luego puedes agregar la nueva funcionalidad. Aquí estamos visitando la ruta del héroe y queremos que se muestre el componente del héroe. Ese es nuestro fallo. Para hacer que las cosas funcionen, simplemente agregamos esa funcionalidad. Decimos bien, agregamos los héroes, deberíamos estar renderizando ese cierto componente. Y ese es un ejemplo de TDD utilizando pruebas de extremo a extremo para el enrutamiento.

Mejores Prácticas Recomendadas

Vamos a repasar las mejores prácticas recomendadas. Hay algunas de estas, así que las repasaremos todas. Con las pruebas de extremo a extremo de la API, no realices pruebas de extremo a extremo de la UI de manera ingenua antes de tener confianza en que tu backend funciona. Debes usar un cliente de prueba de API en lugar de usar tu cliente de UI como cliente de prueba. De esta manera, puedes realizar pruebas antes en tus implementaciones. Debes estar al tanto de los conjuntos de pruebas de tu backend y debes evitar la duplicación. Debes utilizar cantidades moderadas de pruebas de extremo a extremo y realizar un relleno de brechas dirigido cuando tengas pruebas de extremo a extremo de la UI. Ahora no quieres tener que repetir esta prueba de extremo a extremo de la UI si ya tienes confianza en una área. Primero, esta prueba de inicio de sesión funciona. Ahora intenta no hacer el mismo inicio de sesión en cada prueba. Tal vez puedas entrar por la puerta trasera o tener otra forma de iniciar sesión. Cuando el inicio de sesión no funciona, solo una prueba fallará. Y sabes que no está funcionando. No todo tiene que fallar. Aquí tienes tu estrategia de prueba de extremo a extremo de la API para CRUD.

9. Pruebas de Extremo a Extremo de la API y la UI

Short description:

Entonces, es creación, crear y eliminar, actualizar, crear, actualizar y eliminar. La actualización cubre todos los flujos posibles. Este es un ejemplo del backend. Agregamos un héroe, nos aseguramos de que se agregue, lo actualizamos, nos aseguramos de que se actualice correctamente, lo eliminamos y verificamos que se elimine de la base de datos. Las pruebas de extremo a extremo de la UI son similares a las pruebas de extremo a extremo de la API, pero puedes usar los comandos de la API y aislar las pruebas de la UI. Comienza con la creación en la UI y luego realiza la limpieza con la API. La prueba de integración de la UI incluye cancelar, actualizar y agregar un héroe a la lista.

Pruebas de Extremo a Extremo de la API y la UI

Entonces, es creación, crear y eliminar, actualizar, crear, actualizar y eliminar. Y para poder eliminar, primero tienes que crear algo. Pero mira esto. La actualización cubre todos los flujos posibles. Si pruebas la actualización, la creación y la eliminación ya están cubiertas. Así que solo prueba la actualización. Este es un ejemplo del backend. Puedes encontrarlo en el Capítulo 15 y el código final aquí en este enlace.

Estamos agregando un héroe, una solicitud POST. Nos aseguramos de que esa cosa se haya agregado. Hacemos una afirmación. Luego procedemos a editarlo, lo actualizamos. Y luego nos aseguramos de que lo que actualizamos se haya actualizado de la manera que queríamos. Luego realizamos la eliminación y nos aseguramos de que se elimine de la base de datos. Este es el ejemplo de nuestra prueba de extremo a extremo de la API. Y quieres tener esto donde vive el código del backend, lo más cerca posible.

Las pruebas de extremo a extremo de la UI, por otro lado, son muy similares a las pruebas de extremo a extremo de la API. Pero en lugar de eso, puedes usar los comandos de la API que ya has creado y aislar las pruebas de la UI. Por ejemplo, si quieres probar la actualización, puedes ver la base de datos a través del comando de la API que ya hemos escrito. Puedes hacer tus pruebas de UI. Y luego, al final, puedes eliminar. Pasaremos por el ejemplo simple de creación y luego haremos la limpieza con la API. Aquí está esa prueba. También pasaremos por la prueba de integración de la UI. Las primeras son cancelar y actualizar. Y realmente no están utilizando la red real. La última es agregar un héroe. Y después de agregarlo, nos aseguramos de que el héroe esté en la lista. Puedes encontrar la prueba completa aquí.

10. Prueba Final de Extremo a Extremo y Diseño de Pruebas

Short description:

En el capítulo 17, navegamos hasta el héroe, nos aseguramos de que todo esté resuelto, creamos la interfaz de usuario, hacemos afirmaciones y realizamos eliminaciones de la API. Cada paso requiere un desarrollo cuidadoso. Mantén las pruebas de extremo a extremo pequeñas cuando hagas TDD.

Prueba Final de Extremo a Extremo y Diseño de Pruebas

En el capítulo 17, pasamos por esto en el capítulo de consulta de React. Y aquí está la prueba final. Al principio, simplemente navegamos hasta ese héroe. Queremos que todo se resuelva. Estamos utilizando la red real, no hay simulación aquí. Estamos en el lugar correcto. Hicimos la creación de la interfaz de usuario. Así que completamos los detalles, presionamos el botón Guardar. Y luego hacemos nuestras afirmaciones de que estamos en el camino correcto, que hemos agregado esto que se muestra allí. Y finalmente, realizamos las eliminaciones de la API, como vimos antes. Lo que debes tener en cuenta es que cada uno de estos pasos puede requerir mucho desarrollo. Por lo tanto, con las pruebas de extremo a extremo de la API donde estás haciendo TDD, no quieres hacerlas aún más pequeñas porque una línea de prueba de extremo a extremo puede cubrir mucho código fuente. Esta es la idea principal de aquí. Mantén las pruebas de extremo a extremo aún más pequeñas cuando estés haciendo TDD.

11. Pruebas de Integración de la Interfaz de Usuario y Casos de Error

Short description:

¿Qué es una prueba de integración de la interfaz de usuario? Solo utiliza pruebas reales de extremo a extremo cuando sea necesario. Evita duplicar pruebas y aprovecha la funcionalidad del backend. Convierte las pruebas de extremo a extremo de la interfaz de usuario en pruebas de integración de la interfaz de usuario. Prueba la actualización y cancelación utilizando la red real. Utiliza datos simulados en lugar de realizar solicitudes reales. Prueba casos de error y flujos positivos a nivel de componente. Evita probar detalles de implementación y concéntrate en pruebas de caja negra.

Pruebas de Integración de la Interfaz de Usuario y Casos de Error

¿Qué es una prueba de integración de la interfaz de usuario? Por lo tanto, siempre debes evaluar si necesitas tu backend para tener confianza en la funcionalidad de tus aplicaciones. Solo utiliza pruebas reales de extremo a extremo cuando sea necesario para tener esta confianza. Y no deberías tener que repetir esas costosas pruebas de extremo a extremo en todas partes. Ten en cuenta lo que ya está haciendo tu backend y eso hace que tus preocupaciones de extremo a extremo de la interfaz de usuario sean aún menores.

Ten cuidado de no duplicar y trata de obtenerlas. Puedes juzgar a las personas por lo que no hacen, por el costo de las cosas en las que no profundizan. Esto es especialmente cierto para los ingenieros que se llaman a sí mismos comprando una cadena. Convierte una prueba de extremo a extremo de la interfaz de usuario en una prueba de integración de la interfaz de usuario. Aquí tenemos dos pruebas. Una de ellas prueba la actualización, la otra prueba la cancelación. Utilizando la red real, simplemente esperamos a que la red se estabilice antes de continuar y comprobamos que el botón de actualización o el botón de cancelación realiza la cancelación. Solo tienes una prueba de extremo a extremo que agrega un héroe y verifica que la lista se actualice. Por lo tanto, realmente no necesitamos esta solicitud GET real. Puede ser solo datos simulados. Si usamos un archivo JSON, cada vez que accedas a esa ruta en lugar de la cosa real, utiliza el archivo y ahí tienes tus datos. Para poder probar la actualización o la cancelación con confianza, no necesitas el backend. Es un caso de uso perfecto para la prueba de integración de la interfaz de usuario.

Cuando tienes errores, quieres probar tus casos de error. Cualquier prueba que cubra el flujo positivo o el punto de intercepción lateral es un buen punto de ramificación. Intenta probar a nivel de componente. Y si no puedes probar algo, un caso de error negativo, y estás allí, debes pasar a la prueba de integración de la interfaz de usuario. Aquí, este es nuestro escenario positivo. Presionas el botón Guardar y esperamos que se envíe una solicitud POST. Ahí está el lugar perfecto para hacer una prueba de caso de error, un caso que no sea 200. Comenzamos con un 400, también agregamos un retraso y nos aseguramos de que haya un spinner al principio, y luego obtenemos el error. Esto es del capítulo 18, cuando cubrimos suspense, error boundary y concurrencia. Esta prueba por sí sola solo cubre el caso de uso para suspense y error boundary para este componente en particular. Debes evitar probar detalles de implementación. Debes inclinarte más hacia las pruebas de caja negra mientras pruebas tu componente. Y esta es la misma idea de la biblioteca de pruebas de react, que utiliza el servicio worker máximo para hacer lo mismo que estamos haciendo con Cypress intercept.

12. Pruebas de Consecuencias y Retroalimentación Visual

Short description:

Así que en el lado izquierdo, tenemos una prueba de detalle de implementación. Al final, debería realizarse una solicitud de red al backend. Cypress intercept puede hacer las cosas un poco más concisas, un poco más flexibles. Quieres aprovechar la retroalimentación visual de la prueba de componente. Mejora tu TDD, te inspira a buscar más pruebas y te permite detectar estos defectos antes de que incluso ocurran. Ad hoc es posible en una prueba de componente, por lo que puedes ejecutar la prueba de componente y luego tu componente está ahí por sí solo sin leer ninguna otra parte de la aplicación. Es simplemente una experiencia de otro nivel para un desarrollador cuando trabaja en un componente de forma aislada. Aquí hay una prueba final para Navbar, RTL versus prueba de componente Cypress. Cypress puede ser más corto a veces, menos código debido a todos los otros paquetes en comparación con jQuery que viene con él, por lo que es más fácil deseleccionar o obtener los que no están seleccionados en comparación con la otra API en la biblioteca de pruebas de React. Es la misma forma de hacer lo mismo.

Pruebas de Consecuencias y Retroalimentación Visual

Así que en el lado izquierdo, tenemos una prueba de detalle de implementación. Estamos probando que se llame a Testing que utiliza el estado. O se llame a react query. O se llame a nuestro gancho de publicación, nuestro gancho personalizado, cuando hacemos clic en el botón Guardar. En cambio, quieres probar las consecuencias de hacer clic en el botón Guardar. Al final, debería realizarse una solicitud de red al backend. Y es mejor que verifiques esto porque si cambias tu implementación, esta prueba seguirá funcionando. Realmente no importa cómo hacemos los detalles internos. Max service worker y Cypress intercept son muy comparables. Aquí está mi comparación. Puedes verificar los enlaces. En mi opinión, Cypress intercept puede hacer las cosas un poco más concisas, un poco más flexibles. Pero haz tu propia investigación y déjame saber qué piensas.

Quieres aprovechar la retroalimentación visual de la prueba de componente. Así que aquí, en el capítulo ocho, NAVVAR, estoy escribiendo el libro y pensé que esta es una buena prueba. Pero cuando inicio el componente, veo que cada enlace está resaltado. De acuerdo, hago clic en cada uno, voy al enlace correcto. Bien, pero hay un defecto. Esto significa que visualmente, cuando ves el componente, esta calidad de retroalimentación mejora tu TDD, te inspira a buscar más pruebas y te permite detectar estos defectos antes de que incluso ocurran. Obtienes esa retroalimentación de la herramienta de línea de comandos, pero debes tener mucho cuidado. Para mí, fue mucho más fácil ver la cosa visual y pensar, bueno, cuando simplemente hago clic en algo, solo ese elemento debería estar resaltado y el resto no debería estar resaltado. Así que agregué una prueba para eso. La mejor parte es que es posible hacer pruebas ad hoc en una prueba de componente, por lo que puedes ejecutar la prueba de componente y luego tu componente está ahí por sí solo sin leer ninguna otra parte de la aplicación. Puedes hacer clic y explorar, mirar las herramientas de desarrollo, mirar las extensiones. Es simplemente una experiencia de otro nivel para un desarrollador cuando trabaja en un componente de forma aislada. Es simplemente asombroso, esta tecnología. Aquí hay una prueba final para Navbar, RTL versus prueba de componente Cypress. Nuevamente, estilos diferentes, misma intención. Cypress puede ser más corto a veces, menos código debido a todos los otros paquetes en comparación con jQuery que viene con él, por lo que es más fácil deseleccionar o obtener los que no están seleccionados en comparación con la otra API en la biblioteca de pruebas de React. Es la misma forma de hacer lo mismo.

QnA

Usando Wallaby para TDD y Cobertura Combinada

Short description:

Si no puedes usar herramientas visuales, mi consejo es usar Wallaby. Proporciona retroalimentación en línea para TDD y se puede usar desde una CLI o una herramienta IDE. La cobertura combinada te permite asegurar el éxito de tu TDD. Una vez que avanzas más allá de los componentes, TDD con pruebas de punto final se vuelve más relevante. La idea clave de TDD es comenzar con algo que falle, hacer lo mínimo para que funcione y luego mejorarlo. Gracias por escuchar. Comencemos la sesión de preguntas y respuestas discutiendo los resultados de la encuesta. Las pruebas de componentes tomaron la delantera, pero las pruebas unitarias y de extremo a extremo también fueron populares. Sería interesante ver si estos resultados cambian después de la charla.

Usando Wallaby para TDD y Cobertura Combinada

Si no puedes usar herramientas visuales, entonces quieres hacer TDD, mi consejo es usar Wallaby. Recurro a esta herramienta cuando estoy probando el backend, especialmente. Pero si no puedes usar herramientas visuales, si es demasiado difícil migrar, echa un vistazo a Wallaby.js. Te dará retroalimentación en línea mientras escribes tu prueba. Y eso es el punto culminante del TDD, que puedes tener desde una herramienta CLI o IDE. Si puedes tener elementos visuales, al menos ten eso. Puedes usar cobertura combinada para asegurarte de que tu TDD haya sido exitoso. Así que pasa por ese ejemplo en el apéndice del libro. Obtenemos cobertura de Cypress Component Test, obtenemos cobertura de Cypress Endpoint Test y obtenemos cobertura de las pruebas de Jest y React Testing Library. Esto significa que realmente no tienes que migrar de React Testing Library a Cypress Component Testing. Ya puedes tener pruebas con Jest, las pruebas antiguas tal vez, o las pruebas que no son de componentes, tal vez estás probando tus reductores o algo así. Simplemente pueden combinar la cobertura. Y al final, acercarse al 100% de cobertura ya no es un desafío. Es muy fácil. He estado haciendo esto en múltiples proyectos con JavaScript o TypeScript, no importa. La cobertura combinada es el camino a seguir. No es una medida definitiva, pero si tienes una cobertura de código del 100%, nadie va a decir que no confía en su aplicación.

¿Qué hemos aprendido? La calidad de la retroalimentación en Cypress Component Testing mejora el TDD. Ingeniería de componentes y detección temprana de defectos. Una vez que avanzas a enrutamiento, gestión de estado y otras cosas complejas más allá de los componentes, el TDD con pruebas de punto final es más relevante. Con TDD, la idea clave es comenzar con algo que falle, hacer lo mínimo para que funcione y luego intentar mejorarlo. Aquí están los enlaces y referencias, el libro, la aplicación final y la inspiración que contribuyó a este contenido. Muchas gracias por escuchar. Que tengas un buen día, adiós.

Entonces, sí, comencemos la sesión de preguntas y respuestas discutiendo las respuestas a tu pregunta de la encuesta. Me interesó ver que son relativamente similares. Obviamente, las pruebas de componentes tomaron la delantera con un 43%, pero las pruebas unitarias y de extremo a extremo están muy cerca con un 30% y un 26% respectivamente. ¿Qué opinas de esos resultados? Me gustaría saber si hicimos esta encuesta antes y después de la charla, si estos resultados cambiarían. Sí, creo que a medida que avanzamos, comenzamos a ver realmente algunos de los beneficios que destacaste. Será muy interesante ver cuántas personas han cambiado de opinión debido a eso.

Frameworks de JS y Cobertura de Código

Short description:

Las diferencias entre los frameworks de JS para las pruebas de componentes de Cypress radican principalmente en la forma en que se montan los componentes. Las pruebas de componentes de React son similares al montaje regular de una aplicación de React, mientras que Angular y Vue tienen sus propias configuraciones específicas. Lograr cobertura de código con las pruebas de componentes de Cypress depende del framework y el empaquetador utilizados. Cypress permite combinar la cobertura de código entre las pruebas de extremo a extremo y las pruebas unitarias, incluidas las pruebas de componentes. La migración de otras bibliotecas de pruebas a las pruebas de componentes de Cypress permite combinar las pruebas existentes y mantener la cobertura general. Se recomienda utilizar servicios para la integración de la cobertura de código.

Entonces, vamos a tener algunas preguntas aquí de la audiencia, así que vamos a comenzar. La primera pregunta es, ¿cuáles son las diferencias entre los diferentes frameworks de JS para las pruebas de componentes de Cypress? Creo que hay algunas diferencias, ¿verdad? Tienes React, tienes Vue, tienes Angular, y ahora tienes Next.js, entre otros. Por ejemplo, entre Angular y React, ¿verdad? La forma en que se monta el componente es prácticamente la única diferencia. Con las pruebas de componentes de React, será muy similar a cómo se monta tu aplicación regular. Así que si has desarrollado con React antes, estarás muy familiarizado con las pruebas de componentes de Cypress en la variante de React. Pero si has sido desarrollador de Angular, creo que te gustará aún más porque Karma es conocido por tener muchos elementos de boilerplate, y el montaje será, por supuesto, diferente de React, pero te gustará mucho más que montar un componente y configurarlo con boilerplate Karma. Y lo mismo ocurre con Vue. Así que es solo la forma de montar los componentes, el resto es exactamente igual que una prueba de extremo a extremo. Así que si has usado Cypress para pruebas de extremo a extremo, entonces realmente estarás en tu propio juego con las pruebas de componentes de Cypress. Sí, es bueno que puedas aplicar los mismos principios, sin importar qué framework se haya utilizado para desarrollarlo. ¿Tienes alguna pregunta sobre la cobertura de código también? ¿Cómo logras la cobertura de código con las pruebas de componentes de Cypress? Con Jest, viene incluido, ¿verdad? Pero con Cypress, con las pruebas de extremo a extremo, es bastante fácil, algunas extensiones y algunas configuraciones. Con las pruebas de componentes, dependerá de tu framework y dependerá de tu empaquetador. Estoy bastante seguro de que veremos algunas recetas, pero si consultas mi libro, es una aplicación de React que utiliza Webpack, así que hay una buena receta de trabajo allí. Será un poco diferente para Beat, o será diferente para Angular, pero espero que obtengamos algunas recetas del equipo de Cypress porque estoy bastante seguro de que las personas querrán tener cobertura de código en este tipo de pruebas de bajo nivel. Sí, la cobertura de código es definitivamente algo que la gente pregunta y quiere tener en cuenta. ¿Sabes si también se puede combinar la cobertura de código de diferentes tipos de pruebas con las pruebas de componentes de Cypress? Absolutamente, Cypress ha mostrado la combinación de la cobertura de código entre las pruebas de extremo a extremo y las pruebas unitarias regulares de cualquier framework. Simplemente puedes agregar las pruebas de componentes a esta mezcla, puedes combinarlas triplemente, así que, por supuesto, cuando tienes una prueba unitaria en Jest, por ejemplo, y una prueba de componente de Cypress, al combinarlo con la prueba de extremo a extremo, puedes esperar ver que esos números realmente aumenten, lo que también plantea un gran caso de uso para la migración. Entonces, si ya tienes pruebas existentes, digamos en React Testing Library, simplemente puedes mantenerlas allí y si quieres cambiar a las pruebas de componentes de Cypress, puedes hacer tus nuevas pruebas con las pruebas de componentes y simplemente combinar la cobertura y tu cobertura general no disminuirá. Es posible que tengas que depender de servicios, porque hacer esto tú mismo en la integración continua puede no ser muy a prueba de futuro, no es muy fácil, pero hay ejemplos en línea de cómo hacerlo si prefieres hacerlo así. Creo que esa es la forma de hacerlo, utilizando los servicios.

Uso de Pack.js Cypress Adapter para evitar la duplicación de pruebas

Short description:

Para evitar la duplicación de pruebas entre el backend y el frontend, se puede utilizar el adaptador Pack.js Cypress para aprovechar tanto las pruebas de contrato como las pruebas funcionales. Permite probar la integración antes de la implementación, complementando las pruebas de API de extremo a extremo con Cypress. Esto puede ayudar a reducir las pruebas de API de extremo a extremo y crear una arquitectura de pruebas integral. El adaptador se puede utilizar durante la transición a Pack.js.

De acuerdo, genial. Tenemos una pregunta de Marie en el chat. ¿Recomendarías el adaptador Pack.js Cypress como una forma de aprovechar tanto las pruebas de contrato como las pruebas funcionales para evitar la duplicación de pruebas entre el backend y el frontend? Buena pregunta, he pensado mucho en esto y me encanta el vacío que Pack está llenando, porque principalmente te permite probar la integración antes de implementar. Aún no lo hemos implementado, está en nuestros planes hacerlo, pero la forma en que lo imagino es que en el futuro, si podemos implementar Pack, sería un complemento interesante para algunas pruebas de API de extremo a extremo con Cypress, y tal vez podamos reducir un poco esas pruebas de API de extremo a extremo si tienes confianza en algunas pruebas de Pack. Eso permitirá realizar pruebas con Pack de forma más libre y luego, después de implementar, realizar más verificaciones puntuales con Cypress de extremo a extremo, lo que será una buena arquitectura de pruebas. Por supuesto, durante esa transición, podemos utilizar el adaptador, ¿verdad? Podemos aprovechar eso. Sí, creo que lo mencionaste cuando hablaste de la tasa de confianza y de comprender la confianza que ya tienes en tus pruebas existentes en todo el stack, y luego poder construir a partir de ahí con lo que aún necesitas. Y luego, otro aspecto de las pruebas, la otra pregunta que ha surgido aquí, es si se pueden realizar pruebas visuales de captura de pantalla con las pruebas de componentes de la misma manera que se hace con las pruebas de extremo a extremo. Absolutamente. Es solo una línea de código. Y creo que será un poco más estable con las pruebas de componentes porque hay menos partes móviles, ¿verdad? Hemos aplicado esto en nuestra propia biblioteca de pruebas de componentes, lo cual fue muy bueno, por ejemplo, para cientos de variedades de un icono y luego simplemente tomas un antes y un después. Ahorros de costos significativos ahí. Sí. Estamos llegando al final del tiempo, pero también quería preguntar. ¿Crees que es tal vez más impactante realizar pruebas visuales de captura de pantalla con las pruebas de componentes en comparación con las pruebas de extremo a extremo debido a esa estabilidad? Simplemente menos costo para una mayor confianza, ¿verdad? Eso es lo que siempre busco en las pruebas. Absolutamente. Bueno, muchas gracias por estar aquí con nosotros, Murat, para responder estas preguntas. Los asistentes pueden seguir haciendo preguntas en Discord en el canal de Pistas de Producción de Preguntas y Respuestas. Sí, muchas gracias de nuevo por estar aquí. Lo apreciamos mucho. Muchas gracias por invitarme. Adiós. ♪♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 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!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.