CCTDD: Diseño impulsado por pruebas de componentes Cypress

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.

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.

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.

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.

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.

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.

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.

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.

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í.

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.

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.

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.

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.

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.

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. ♪♪