Jest 14.0: Pruebas de Instantáneas de Árbol React

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Una de las filosofías de Jest es ofrecer una experiencia integrada "sin configuración". Queremos que escribir buenas pruebas útiles sea lo más sencillo posible. Observamos que cuando los ingenieros tienen herramientas listas para usar, terminan escribiendo más pruebas, lo que a su vez resulta en bases de código estables y saludables.

Una gran pregunta pendiente era cómo escribir pruebas de React eficientemente. Existen muchas herramientas como ReactTestUtils y enzyme. Ambas son excelentes y se usan activamente. Sin embargo, los ingenieros frecuentemente nos comentaban que dedicaban más tiempo escribiendo una prueba que el componente en sí. Como resultado, muchas personas dejaron de escribir pruebas por completo, lo que eventualmente llevó a inestabilidades. Los ingenieros nos dijeron que solo querían asegurarse de que sus componentes no cambiaran inesperadamente.

Junto con el equipo de React, creamos un nuevo renderizador de pruebas para React y añadimos pruebas de instantáneas a Jest. Considera esta prueba de ejemplo para un sencillo componente Link:

import renderer from 'react-test-renderer';
test('Link renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

La primera vez que se ejecuta esta prueba, Jest crea un archivo de instantánea que luce así:

exports[`Link renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function bound _onMouseEnter]}
  onMouseLeave={[Function bound _onMouseLeave]}>
  Facebook
</a>
`;

El artefacto de instantánea debe guardarse junto con los cambios de código. Usamos pretty-format para que las instantáneas sean legibles durante la revisión de código. En ejecuciones posteriores de pruebas, Jest simplemente comparará el resultado renderizado con la instantánea anterior. Si coinciden, la prueba pasará. Si no coinciden, o la implementación cambió y la instantánea necesita actualizarse con jest -u, o el ejecutor de pruebas encontró un error en tu código que debe corregirse.

Si cambiamos la dirección a la que apunta el componente Link en nuestro ejemplo, Jest mostrará esta salida:

Ahora sabes que necesitas aceptar los cambios con jest -u o corregir el componente si los cambios no fueron intencionales. Para probar esta funcionalidad, clona el ejemplo de instantáneas, modifica el componente Link y ejecuta Jest. Actualizamos el Tutorial de React con una nueva guía para pruebas de instantáneas.

Esta funcionalidad fue desarrollada por Ben Alpert y Cristian Carlesso.

Soporte experimental para React Native

Al crear un renderizador de pruebas que no apunta a ninguna plataforma específica, finalmente podemos soportar una versión completa sin mocks de React Native. Nos entusiasma lanzar soporte experimental para React Native en Jest mediante el paquete jest-react-native.

Puedes comenzar a usar Jest con react-native ejecutando yarn add --dev jest-react-native y añadiendo el preset a tu configuración de Jest:

"jest": {
  "preset": "jest-react-native"
}

• Tutorial y guía de configuración

• Proyecto de ejemplo

• Pull request de ejemplo para snowflake, una popular biblioteca open source de react-native.

información

Actualmente, el preset solo implementa el conjunto mínimo de configuración necesario para comenzar con pruebas de React Native. Esperamos contribuciones de la comunidad para mejorar este proyecto. ¡Pruébalo y reporta issues o envía pull requests!

¿Por qué pruebas de instantáneas?

Para las aplicaciones nativas de Facebook, usamos un sistema llamado "pruebas de instantáneas": un sistema que renderiza componentes de UI, toma una captura de pantalla y luego compara la captura grabada con los cambios realizados por un ingeniero. Si las capturas no coinciden, hay dos posibilidades: o el cambio es inesperado o la captura puede actualizarse a la nueva versión del componente.

Si bien esta era la solución que queríamos para la web, también encontramos muchos problemas con estas pruebas end-to-end que las pruebas de integración con snapshots resuelven:

• Sin fragilidad: Como las pruebas se ejecutan en un entorno de línea de comandos en lugar de un navegador real o un teléfono, el runner no necesita esperar builds, lanzar navegadores, cargar páginas ni manipular la UI para llevar un componente al estado esperado, procesos que suelen ser frágiles y generar ruido en los resultados.

• Velocidad de iteración: Los desarrolladores quieren resultados en menos de un segundo en lugar de esperar minutos o incluso horas. Si las pruebas no son rápidas como en la mayoría de frameworks end-to-end, los desarrolladores no las ejecutan o ni siquiera se molestan en escribirlas.

• Depuración: Es fácil analizar el código de una prueba de integración en JS en lugar de recrear escenarios de pruebas de captura de pantalla y depurar diferencias visuales.

Como creemos que las snapshot tests pueden ser útiles más allá de Jest, dividimos esta funcionalidad en el paquete jest-snapshot. Estamos encantados de colaborar con la comunidad para hacerlo más genérico e integrarlo con otros test runners, compartiendo conceptos e infraestructura.

Finalmente, citamos a un ingeniero de Facebook describiendo cómo las snapshot tests transformaron su experiencia con pruebas unitarias:

“Uno de los mayores desafíos en mi proyecto era mantener sincronizados los archivos de entrada y salida para cada caso de prueba. Cada pequeño cambio funcional podía alterar todos los archivos de salida. ¡Con las snapshot tests ya no necesito archivos de salida porque Jest genera las instantáneas automáticamente! Puedo inspeccionar cómo Jest actualiza las snapshots en lugar de hacer cambios manualmente.” – Kyle Davis trabajando en fjs.

¿Qué sigue para Jest?

Recientemente Aaron Abramov se unió al equipo de Jest a tiempo completo para mejorar nuestra infraestructura de pruebas unitarias e integradas en los productos de anuncios de Facebook. En los próximos meses, el equipo planea mejoras importantes en estas áreas:

• Reemplazar Jasmine: Jasmine nos ralentiza y no tiene desarrollo activo. Comenzamos a reemplazar sus matchers y estamos emocionados de añadir nuevas funciones mientras eliminamos esta dependencia.

• Cobertura de código: Cuando se creó Jest originalmente, herramientas como Babel no existían. Nuestro soporte de cobertura tiene casos extremos problemáticos y no siempre funciona correctamente. Lo estamos reescribiendo para resolver estos problemas.

• Experiencia del desarrollador: Mejoraremos el proceso de configuración, la depuración, la CLI y documentación.

• Mocks: El sistema de mocks, especialmente los manuales, no funciona bien y resulta confuso. Buscamos hacerlo más estricto e intuitivo.

• Rendimiento: Seguimos trabajando en mejoras de rendimiento para codebases muy grandes.

Como siempre, si tienes preguntas o quieres colaborar, ¡contáctanos!