Los Tests End-to-End molan… si sabes cómo hacerlos

El testing End to End (E2E) es aquel que se encarga de validar la aplicación al completo. Este tipo de tests se llevan a cabo de principio a fin, en escenarios reales que prueban la comunicación de la aplicación con el hardware, redes o bases de datos, entre otras.

Sin embargo, ¿qué es lo primero que te viene a la cabeza cuando hablamos de Test E2E? Si tu respuesta es que estos tests son complejos, tediosos y muy difíciles de implementar, no puedes perderte la charla de Gustavo Marín, NodeJS Team Leader en Intelygenz, en nuestro último meetup.

Un taller en el que nuestro crack te enseña a desarrollar tests E2E sin morir en el intento: repasando frameworks útiles, analizando los errores más comunes, buenas prácticas y los fundamentos del patrón Page Object para hacer tests comprensibles y de fácil mantenimiento.

¿Qué tipos de tests podemos encontrar?

Nuestro compañero empezó por el principio, con una breve explicación de los distintos tests a los que podemos hacer frente:

  • Tests Unitarios. Prueban una unidad de código.
  • Test de Integración. Prueban que diferentes componentes de tu aplicación funcionan correctamente entre sí.
  • Tests de UI. Aquellos que ejecutas y que pasan por la interfaz final de usuario de tu aplicación.
  • Tests de Aceptación. Prueban la implementación contra los requisitos establecidos, explorando una parte concreta del sistema y verificando que el producto cumple su propósito.
  • Test E2E. Como los anteriores también prueban la implementación contra los requisitos con la diferencia que estos últimos incluyen todas las dependencias en las que no tenemos propiedad (como una API externa). Prueban la aplicación en su conjunto y no como partes separadas.

Esta primera introducción concluía con dos referencias:

La primera sobre la conocida Pirámide del Testing, que se explica dentro del post  End-To-End Testing Considered Harmful”.

La Pirámide del Testing - In Code we Trust by Intelygenz

Y una segunda sobre el artículo Exploring the top of the testing pyramid: End-to-end and user interface testing , que explica cómo a veces la clasificación de los tests varía según la estrategia con la que decidas programarlos y ejecutarlos.

¿Por qué emplear Tests E2E?

Los tests End to End tienden a ser conocidos por una serie de características negativas como su complejidad, ya que suponen una alta curva de aprendizaje y resulta difícil programar interacción de usuario; el tiempo que nos pueden suponer, puesto que se trata de tests un tanto lentos de ejecutar y a veces pueden fallar sin razón aparente; la percepción que desde la esfera de negocio puede tenerse sobre ellos, ya que sus ventajas tienden a aparecer a medio/largo plazo, o su tendencia a "romper la ilusión de los developers".

Sin embargo, también pueden proporcionarnos importantes ventajas. A lo largo del meetup, Gustavo se encargó de hablarnos de las “bondades” de este tipo de tests destacando la idea de que que nos permiten obtener información sobre nuestro sistema, lo que radica en una mayor confianza durante el desarrollo y que, además, son fáciles de automatizar, permitiéndonos ahorrar mucho tiempo en el ciclo de desarrollo.

Test E2E + ATDD, la unión hace la fuerza

Una de las técnicas que utilizamos en Intelygenz para desarrollar Tests E2E exitosos es su combinación con ciertos puntos de ATDD. Entre ellos, encontramos la posibilidad de hacerlos casi en lenguaje natural, el documentar el sistema desde el punto de vista del usuario o implicar al equipo al completo.

Buenas prácticas trabajando con Tests End to End

A pesar de todo, nos contaba nuestro crack que, cuando trabajamos con tests end-to-end no es fácil llegar a un punto exitoso. Por este motivo os dejamos un conjunto de buenas prácticas que hemos ido aprendiendo en Intelygenz que y nos han llevado a confiar en esta forma de testear:

Creación y Contenido:

  • Definir los tests junto al Product Owner, pero dejando que sean escritos por un desarrollador.
  • Escribir los tests con Gherkin.
  • Emplear la perspectiva de usuario.
  • Hacer tests independientes entre sí.
  • Cuando sea necesario “condensar” los pasos anteriores.

Consejos técnicos:

  • Hacer un test simple modo “sonda”.
  • Evitar poner timeouts si el framework de tests lo permite.
  • Con Protactor/Node usamos async/await.
  • Emplear los fundamentos del patrón Page Object para hacer tests comprensibles y de fácil mantenimiento:
    • encapsulamos las APIs de Webdriver/HTML,
    • no hacemos “assertions” en los métodos del PageObjects,
    • no usamos xpath.

Consejos Generales:

  • Intentar “educar” a nuestro Product Owner;
  • Hacer “trampas” o utilizar atajos cuando sea necesario,
  • Automatizar la ejecución de los tests,
  • No pretender cubrir el 100% de la aplicación con tests E2E
  • Completar el testeo con tests manuales y exploratorios.

Todo esto y mucho más, dándole al play! #InCodeWeTrust

 

¿Te gustaría trabajar con nosotros? Genial ¡te esperamos!