E2E Testing: Un tutorial y una guía de arquitectura
Las pruebas de extremo a extremo (E2E) ayudan a validar los flujos más importantes de su aplicación, como las solicitudes de inicio de sesión de los usuarios. Para el desarrollo del front-end, las pruebas E2E ayudan a verificar si se ha presentado la UI correcta. Para el desarrollo de back-end, las pruebas E2E ayudan a verificar si un flujo importante en sus servicios de back-end devuelve la salida esperada.
Este post le introducirá a las pruebas E2E y le dará consejos prácticos. También explicaremos cómo escribir pruebas reutilizables para que puedan ser utilizadas para crear pruebas E2E más fácilmente. Como ya sabrás, las pruebas E2E son a menudo una gran frustración para los desarrolladores, ya que requieren mucho esfuerzo para escribir, ejecutar y mantener.
En primer lugar, vamos a echar un vistazo a donde se encuentra la prueba E2E en la pirámide de pruebas de software.
Lugar de las pruebas E2E en la pirámide de pruebas
Al observar la pirámide de pruebas, encontramos cuatro tipos principales de pruebas que nos ayudan a garantizar la calidad del código:
- Las pruebas E2E ayudan a verificar las rutas de alto valor en su aplicación. En otras palabras, ayudan a verificar las historias de usuario, ya que a menudo representan flujos en su aplicación.
- Las pruebas de integración ayudan a verificar la integración de múltiples funciones o componentes. Las pruebas de integración pueden decirle si su código funciona de forma cohesiva con otras funciones.
- Las pruebas unitarias ayudan a verificar la lógica de negocio de las funciones. Las pruebas unitarias son la forma más básica de pruebas, y aseguran que la lógica de negocio es correcta.
- Por último, no podemos olvidarnos del análisis estático o pruebas estáticas. Las pruebas estáticas ayudan a encontrar erratas o errores de tipo.
Según esta pirámide, la mayoría de las pruebas deben ser unitarias, con menos pruebas de integración y aún menos pruebas E2E. Sin embargo, sigue siendo importante verificar los flujos en su aplicación. Las pruebas E2E son difíciles de mantener y requieren mucho esfuerzo. Por lo tanto, sólo verifique los flujos más importantes con pruebas E2E. Otros tipos de pruebas, como las de integración y las unitarias, ya deberían darle suficiente confianza a su código base.
Diferentes estrategias de pruebas E2E
Déjeme decirle que existen diferentes estrategias. Podemos elegir entre las pruebas E2E horizontales y las pruebas E2E verticales. Vale la pena explorar ambas estrategias ya que permiten probar diferentes escenarios. Aprendamos lo que hace cada estrategia.
Estrategia #1: Pruebas verticales de extremo a extremo
Esta estrategia se centra en probar todas las capas de la pirámide de pruebas. Incluye pruebas unitarias, pruebas de integración y pruebas de interfaz de usuario. Su objetivo es probar un componente a nivel granular utilizando pruebas unitarias, probar cómo se comporta un componente cuando interactúa con otros componentes utilizando pruebas de integración y, por último, verificar el comportamiento del componente cuando los usuarios interactúan a través de la UI.
Lo más habitual es utilizar un pipeline de integración continua para automatizar estas pruebas para cada commit de código o pull request.
Estrategia #2: Pruebas horizontales de extremo a extremo
Las pruebas horizontales E2E se centran en verificar un flujo de usuario completo. Aquí hay un ejemplo de flujo para una tienda web:
- Abrir la página del producto
- Seleccionar el tamaño del producto
- Añadir el producto a la cesta de la compra
- Ir a la caja
- Completar la dirección y la información de pago
- Completar el pago
- Mostrar la pantalla de confirmación de la compra
Aquí, queremos verificar cada transacción del flujo de usuario. A menudo, este tipo de pruebas verifica la interacción entre diferentes aplicaciones y verifica los cambios de estado para esas aplicaciones.
Tenga en cuenta que este tipo de pruebas son caras de escribir. Se requiere bastante tiempo para definir los flujos de usuarios y escribir estas pruebas. Por lo tanto, intente centrarse en las rutas de transacción críticas para su aplicación.
Sin embargo, asegúrese de probar estos flujos de usuario críticos para diferentes condiciones. Esta estrategia le permite obtener una imagen completa de la robustez del flujo de usuario. Estas condiciones incluyen:
- Escenarios de tiempo complejos: Por ejemplo, una entrada para un concierto sólo está disponible para ti durante 15 minutos.
- Diferentes entradas de datos o datos que faltan.
- Rupturas del flujo: Un usuario decide abandonar la página de compra para ver otra página de producto. Por ejemplo, necesitamos verificar si el componente guarda el estado del checkout.
A continuación, vamos a aprender cuándo escribir pruebas E2E.
Cuándo escribir pruebas E2E
Puede que no sepas que las pruebas E2E son pruebas caras de ejecutar en tu pipeline de integración continua. A menudo requieren mucha preparación, como la creación de una base de datos que imita los datos de producción. Además, a veces representan flujos que consumen mucho tiempo en su aplicación. Por lo tanto, pueden ser lentos y requerir más recursos para ser ejecutados.
Utilice las pruebas E2E para verificar los flujos más importantes de su aplicación. Ejemplos de flujos de alto valor incluyen:
- Inicio y cierre de sesión
- Registro de un nuevo usuario
- Añadir artículo al carrito
- Cambiar su contraseña
- Cualquier otro flujo importante relacionado con su servicio
Sin embargo, no olvide verificar la lógica de negocio que escriba con pruebas unitarias y de integración. La combinación de pruebas unitarias y de integración debería darle mucha confianza sobre la calidad de su código. Las pruebas E2E le ayudan a aumentar esta confianza para las rutas críticas.
Aquí hay algunos consejos procesables para escribir pruebas E2E.
Consejos para escribir pruebas E2E
Enfóquese en escribir pruebas reutilizables
El primer y más importante consejo es escribir pruebas y componentes pequeños, independientes y reutilizables. Esto le permite encadenar múltiples componentes pequeños para crear flujos de usuario completos de extremo a extremo más fácilmente. En lugar de escribir un montón de componentes personalizados sólo para ser utilizados por las pruebas E2E, céntrate en escribir componentes reutilizables.
Escribir componentes pequeños e independientes ayuda a la reutilización del código y reduce el tiempo de resolución de errores. Además, es más fácil actualizar los componentes pequeños cuando la funcionalidad o los flujos de usuario cambian.
Considere siempre la razón para escribir una prueba E2E
Cuando quiera cubrir un flujo particular con una prueba E2E, considere si vale la pena cubrirlo. Sólo pruebe los flujos de usuario de alto valor con pruebas E2E. Por ejemplo, no debería probar si se muestra un mensaje de error cuando un usuario introduce una dirección de correo electrónico incorrecta. Este es un caso de uso demasiado simple que no encaja en una prueba E2E. Este requisito puede ser simplemente probado con una prueba de unidad.
Por otro lado, vale la pena probar si la página de inicio de sesión le redirige a la página correcta de la aplicación después de iniciar la sesión con éxito. Este es un flujo valioso para que tus usuarios puedan utilizar la aplicación. En resumen, considere siempre la razón para escribir una prueba E2E.
Las pruebas E2E no deben depender de los detalles de implementación
No querrá actualizar las pruebas E2E cada vez que cambie los detalles de implementación de un determinado flujo. Por lo tanto, quiere escribir componentes que le permitan abstraer los detalles de implementación. Las pruebas E2E se vuelven mucho más fáciles de mantener, y más divertidas de escribir, cuando los detalles de implementación se ocultan en los componentes. En resumen, las pruebas E2E deben ser independientes de los detalles de implementación.
A continuación, vamos a ver las trampas de las pruebas E2E.
Trampas de las pruebas E2E
Aquí hay una lista de trampas comunes asociadas con las pruebas E2E:
- Las pruebas E2E no deben tratar de probar todo lo posible de una sola vez. A menudo, los desarrolladores escriben enormes pruebas E2E que verifican todos los aspectos del flujo de usuario. Mantenga las cosas simples y verifique los aspectos más importantes de su flujo de usuario. Por ejemplo, para un flujo de inicio de sesión, sólo necesita verificar si el usuario fue redirigido a la página de la aplicación. Esto facilitará a los desarrolladores el mantenimiento y la actualización de las pruebas E2E.
- Cuando una prueba E2E falla, puede ser difícil encontrar la causa exacta del fallo. Sin embargo, puede reducir los esfuerzos de depuración necesarios cubriendo su lógica de negocio con pruebas unitarias y de integración. Algunas herramientas también proporcionan un buen análisis de la causa raíz, incluyendo capturas de pantalla y registros de consola de los pasos de prueba fallidos, lo que puede reducir el tiempo de resolución de problemas.
- Las pruebas E2E requieren una cantidad considerable de tiempo en su tubería de integración continua (CI). Pueden bloquear su canalización CI, lo que ralentiza el desarrollo en general. Esto significa que es posible que tenga que invertir en su tubería de CI para tener algunas tuberías más para ejecutar pruebas.
- Las pruebas E2E son un esfuerzo continuo. Cada vez que se añade una nueva funcionalidad o cambia la antigua, es probable que tenga que actualizar sus pruebas E2E. Sin embargo, podemos reducir este esfuerzo escribiendo componentes reutilizables que abstraigan los detalles de implementación. Además, algunas herramientas utilizan la IA para ayudar a adaptar las pruebas cuando el código cambia, reduciendo el mantenimiento de las pruebas.
Ahora, echemos un breve vistazo a las diferencias entre las pruebas del sistema y las pruebas E2E.
Pruebas del sistema frente a pruebas E2E – ¿Cuál es la diferencia?
Entonces, ¿cuál es la diferencia entre las pruebas del sistema y las pruebas E2E? La prueba del sistema se centra en la validación de los requisitos funcionales y no funcionales. A menudo, lo realiza un equipo externo que trata la aplicación como una caja negra. En otras palabras, no saben nada sobre el funcionamiento de la aplicación, excepto los requisitos que debe cumplir.
Sin embargo, esta forma de pruebas se confunde a menudo con las pruebas E2E, ya que las pruebas del sistema son una forma de pruebas E2E. Sin embargo, las pruebas del sistema verifican mucho más que las pruebas E2E. Por ejemplo, las pruebas del sistema miden la escalabilidad, el rendimiento o la fiabilidad. Mientras que las pruebas E2E se centran en la correcta finalización de los flujos de usuario.
Por último, vamos a resumir los aprendizajes de este artículo.
Conclusión sobre E2E
Las pruebas de extremo a extremo son muy poderosas ya que ayudan a validar los flujos de usuario de alto valor o historias de usuario. Ayudan a garantizar la calidad de su aplicación.
Sin embargo, escribir y mantener las pruebas E2E puede requerir un tiempo y esfuerzo significativo. Es posible reducir este esfuerzo escribiendo componentes pequeños y reutilizables que abstraigan los detalles de la implementación. Algunas herramientas también ayudan a crear pruebas más resistentes utilizando IA o múltiples atributos para identificar cada elemento. Por lo tanto, no es necesario actualizar las pruebas E2E cada vez que los detalles de implementación cambian para los flujos de usuario de alto valor. Además, los componentes reutilizables le permiten encadenar esos componentes para crear flujos de pruebas E2E fácilmente.
Las pruebas E2E deben cubrir los flujos más importantes de su aplicación. Prueban los flujos que sus usuarios y clientes siguen para obtener valor de su aplicación. Si no pueden iniciar sesión o añadir un artículo a un carrito, se irán (si pueden) o llamarán al servicio de asistencia si se ven obligados a utilizar su aplicación. Por ejemplo, usted quiere cubrir el flujo de inicio y cierre de sesión, pero está menos interesado en verificar un mensaje de error después de introducir una dirección de correo electrónico incorrecta.
Al final, las pruebas E2E deben ser divertidas de escribir. No deben requerir mucho tiempo y esfuerzo para escribir y mantener. Mantén las pruebas E2E simples y céntrate en componentes reutilizables, y verás grandes resultados.
Este post fue escrito por Michiel Mulders. Michiel es un apasionado desarrollador de blockchain al que le encanta escribir contenido técnico. Además de eso, le encanta aprender sobre marketing, psicología UX y emprendimiento. Cuando no está escribiendo, probablemente esté disfrutando de una cerveza belga.