Descripción general de las pruebas
¿Qué se debe someter a pruebas?
Las aplicaciones de Jutro siguen la filosofía de React de componer a partir de componentes. Las interfaces de usuario de Jutro se crean a partir de componentes atómicos. Estos componentes se componen en páginas. Luego, un plano de planta administra las páginas.
Cada parte de la interfaz de usuario es técnicamente un componente, incluso una página es un componente. Por lo tanto, probar la aplicación es sinónimo de probar componentes.
Pruebas de extremo a extremo
Las interacciones típicas del usuario implican el uso de varios componentes. Las pruebas de extremo a extremo (e2e) conllevan probar grupos de componentes, una página completa o incluso varias páginas de una aplicación. Usted escribe pruebas que “hacen clic”, “completan campos”, “arrastran y sueltan elementos” y llevan a cabo otras acciones que realizaría un usuario.
De extremo a extremo es la forma más eficaz de verificar la funcionalidad de su aplicación y la más fácil de planificar. Refleja los principales recorridos de sus usuarios en las pruebas y siempre estará seguro de que el usuario puede hacer lo que necesita en su aplicación.
Visuales
Las pruebas visuales en Jutro dependen de TestCafe. TestCafe crea una captura de pantalla y la compara con una anterior. Esto le permite detectar cualquier cambio accidental.
Para mantener la coherencia, las pruebas se ejecutan utilizando exploradores específicos, generalmente en una imagen de Docker.
Problemas conocidos
Hay un problema conocido cuando testcafe usa hummerhead que puede ocasionar que los microfrontends fallen de forma aleatoria durante la renderización. Para resolver este problema, actualice testcafe a la versión 3.x.x, ya que las versiones más recientes no utilizan hummerhead de forma predeterminada. En caso de que deba usarlo, utilice la opción --disableNativeAutomation.
Unitarias
Algunas funcionalidades son más teóricas que las interacciones del usuario. Las pruebas unitarias le permiten confirmar que incluso las partes más pequeñas de su aplicación funcionan según lo previsto. Cuando se escriben pruebas unitarias para aplicaciones de Jutro, por lo general se prueban cosas como estas:
- Se verifica si la aplicación se renderiza sin bloquearse.
- Se verifica si un componente basado en metadatos tiene metadatos válidos.
- Se verifica si una función que se supone que acorta descripciones largas realmente devuelve strings de longitud especificada y no se bloquea cuando la descripción es más corta que la longitud especificada.
- Se verifica si se llama a una devolución de llamada.
- Se verifica si un efecto secundario se desencadena la cantidad adecuada de veces.
Accesibilidad
Las pruebas de accesibilidad (a11y) destacan los problemas que pueden tener al usar su aplicación las personas con algún tipo de discapacidad visual, auditiva, de movilidad o de otro tipo. Usamos jest-axe para probar automáticamente los aspectos básicos de a11y, pero le recomendamos encarecidamente que realice un seguimiento con pruebas manuales. Esta es la única manera segura de garantizar el nivel deseado de accesibilidad en su aplicación.
Explicación del flujo de trabajo
Para optimizar su experiencia de desarrollo, le recomendamos el siguiente flujo de trabajo:
- Escriba una prueba e2e de su funcionalidad.
- Escriba pruebas unitarias para definir todos los pequeños detalles de cada componente individual.
- Desarrolle cada componente para crear la funcionalidad general hasta que pasen todas las pruebas.
- Verifique la accesibilidad (esto puede cambiar el aspecto de su aplicación).
- Agregue pruebas visuales para registrar el aspecto deseado de su componente, grupo de componentes o página.
- Asegúrese de que sus pruebas se ejecuten y resulten satisfactorias en TeamCity en cada solicitud de extracción.