Table of Contents
Según el Tío Bob, el testing forma parte del sistema, lo que muchos desarrolladores creen que es lo contrario, ya que no se despliegan. Declara que es un punto de vista catastrófico ya que el papel del testing es apoyar el desarrollo y mantener el sistema robusto y fácil de cambiar. (Arquitectura limpia, Robert C. Martin, 2018)
En el Front End se comprueban comúnmente las interacciones de los usuarios finales con nuestra aplicación. Debemos garantizar a nuestros usuarios que cuando se conecten, abran un pop-up, añadan un comentario o realicen cualquier otra interacción con nuestras aplicaciones no se encuentren con ningún error y vivan experiencias no deseadas.
El testing en Frontend, si se hace correctamente, conseguirá que nuestros usuarios estén contentos y tengan una experiencia de buen rendimiento utilizando nuestras aplicaciones. Por otro lado, para los desarrolladores ahorrará mucho tiempo a la hora de resolver bugs o al añadir nuevas funcionalidades no romperá comportamientos anteriores del código.
¿Por qué el testing puede ser desventajoso? ¿Cómo diseñar un sistema de testing?
El testing requiere tiempo y también coherencia con los cambios durante el desarrollo. Además, con la evolución de los dispositivos y los navegadores, hay que estar al día. En el testing de software existe un concepto conocido como el Fragile Tests Problem. Esto se puede definir como un cambio en un sistema que hace que cientos de pruebas fallen. El tío Bob hace hincapié en la importancia de un sistema de pruebas bien diseñado para obtener los beneficios deseados de estabilidad y regresión para nuestros sistemas (Clean Architecture, Robert C. Martin , 2018).
Describiremos algunas metodologías y estrategias que pueden ayudar al diseño de nuestros sistemas de pruebas:
Martin Fowler, en su artículo «On the Diverse And Fantastical Shapes of Testing, cuenta el momento en que le preguntaron a un experto en testing la definición del test unitario. Dice que la respuesta de este experto cubrió 24 definiciones diferentes de test unitario en la primera mañana de su curso de formación. Como hay muchas definiciones diferentes de la test unitario, en este artículo incluiremos la que Fowler llama «solitary test».
En la famosa pirámide de testing, en la base encontramos los tests unitarios que tienen menos cobertura de tests pero son los más rápidos de ejecutar. En el segundo nivel, vemos los tests de integración que tienen más cobertura pero son más lentos ya que pueden conectarse con partes externas. Por último tenemos los tests E2E o lo que algunos llaman tests de aceptación que cubren una gran parte de la aplicación pero son las más lentos de ejecutar.
Los tests unitarios, comprueban que nuestros componentes de forma aislada funcionan correctamente. También cubren los casos extremos para testearlos y esto lleva a nuestra base de código a ser más fiable. A las pruebas o tests unitarios les sigue la realización de tests de integración. Los tests de integración comprueban la comunicación entre dos unidades o módulos de software desarrollados de forma independiente cuando se conectan entre sí. Analizan el comportamiento de los sistemas cuando están conectados y también comprueban la interacción entre los microservicios. También incluyen la conexión api, por lo que son más lentos que las tests unitarios, ya que la conexión puede retrasarse o el servicio puede estar caído. En el frontend, los tests de integración se utilizan para comprobar que los datos que devuelve la api tienen el objeto, array o formato correcto.
Los tests E2E simulan el comportamiento del usuario y comprueban todas las interacciones de éste con nuestra aplicación. Son versiones especializadas de los tests de integración que se ejecutan en navegadores reales. Generalmente se ejecutan antes de las fusiones o lanzamientos, ya que puede llevar horas terminar la ejecución de la prueba.
A continuación, mencionamos también las técnicas de testing como la accesibilidad y la interfaz de usuario:
Las pruebas de accesibilidad comprueban que la interfaz de usuario es fácilmente utilizable por todos los usuarios y hacen que nuestra aplicación sea utilizable por personas con discapacidad. Jest-axe es una gran librería de testing en Jest que nos permite comprobar la accesibilidad de nuestras aplicaciones. También puedes consultar este artículo de mi colega Serhii, para una explicación completa en los tests de accesibilidad.
Los tests de UI comprueban si la interfaz de usuario de nuestra aplicación funciona correctamente. Si un usuario introduce una entrada, hace clic en una casilla de verificación, borra un elemento, debe funcionar correctamente y actualizar el estado de la UI como se espera.
Revisión de algunas librerías de testing para Frontend
Jest es una librería utilizada principalmente para tests unitarios y de integración en Frontend. Es muy rápida para proyectos grandes con muchos archivos de test por su mecanismo de implementación de testing paralelo inteligente.
Testing Library es una biblioteca con la que podemos escribir tests unitarios y de integración. Ayuda con selectores convenientes, disparando eventos, configuración, tratando con código asíncrono, y mucho más.
Cypress es una librería que inyecta sus tests en un sitio web que Cypress.io ejecuta por sí mismo en el navegador. Podemos escribir tests unitarios, de integración y end-to-end de manera eficiente.
Proporciona una experiencia más rápida a los desarrolladores y podemos ver los errores fácilmente en el navegador.
Applitools se utiliza para los tests de regresión visual. Con sus avanzadas técnicas de IA detecta las diferencias entre las imágenes y el DOM. Es muy útil para comprobar si la apariencia de nuestra web es la misma que la anterior o si se ha producido algún error. También comprueba para diferentes navegadores y plataformas si el usuario puede ver correctamente cualquier elemento, tal como un botón en el sitio web o en móvil.
Conclusión
El testing en frontend debería formar parte de nuestros desarrollos para solucionar los problemas de nuestro código antes de que pasar a producción. Debemos escribir tests unitarios que examinen cada funcionalidad de nuestras aplicaciones, y también desarrollar tests de integración para comprobar si todos los componentes y módulos funcionan correctamente juntos. Por otro lado, deberíamos escribir tests E2E que automatizan los tests manuales y centran cómo los usuarios interactuarían con nuestra aplicación.
Debemos escribir tests para proporcionar confianza y no sólo para mejorar las métricas. Como dice Robert C. Martin debemos evitar escribir tests que estén fuertemente acoplados al sistema. Porque incluso el cambio más trivial puede generar muchos tests para romper.
Referencias
On the Diverse And Fantastical Shapes of Testing por Martin Fowler @Martin Fowler Blog
Integration Test por Martin Fowler @Martin Fowler Blog
An Overview of JavaScript Testing in 2022 por Vitali Zaidman @Medium
Cypress Framework: The Swiss Army Knife For Your Tests por Serhii Zabolennyi @Apiumhub
Practical Test Pyramid por Martin Fowler @Martin Fowler Blog
Front-End Testing is For Everyone por Egeny Klimenchenko @CSS-Tricks
JavaScript Testing: Unit vs Functional vs Integration Tests por Eric Elliot @Sitepoint
Most Popular Front End Automation Testing Tools in 2022 por Bethany wilson at @Medium
Cypress: The future of end-to-end testing for web applications por Evelyn Chan @Quizlet
