Configuración de un entorno de extremo a extremo perfectamente aislado

Para pruebas estables de extremo a extremo (E2E), necesitamos un entorno que esté lo más aislado posible del exterior.

Reducir la descamación

Las pruebas escamosas son pruebas que fallan por razones no relacionadas con su código. Hacen que sea difícil usar E2E como una verificación confiable de la corrección de la aplicación. En casos extremos, las pruebas escamosas le enseñarán a su equipo a ignorar los resultados de E2E. Esto puede acabar con el esfuerzo de automatizar el control de calidad (QA).

El enfoque que se presenta aquí aborda dos grandes fuentes de problemas potenciales en sus ejecuciones de prueba:

• Estado almacenado por el backend compartido por diferentes trabajos de prueba, y

• Servicios externos sobre los que no tienes control.

Hay otras fuentes de descamación que no se ven afectadas por este enfoque:

• El verdadero problema está en la aplicación que apareció al azar, o

• Los problemas en la aplicación se deben a la velocidad poco natural a la que E2E interactúa con ella.

Alternativa

Antes de que mi equipo y yo realizáramos mis pruebas en un contenedor back-end dedicado, usamos uno de nuestros servidores que no son de producción. Este enfoque estuvo bien en la etapa de experimentación de nuestra solución E2E.

Cuando solo había unas pocas pruebas, no podíamos usar los resultados de las pruebas para tomar decisiones de todos modos.

Sin embargo, a medida que agregamos más pruebas y generamos tiempos de ejecución más prolongados, este enfoque comenzó a desmoronarse. Los principales problemas fueron los siguientes:

• Aunque intentamos revertir los cambios de datos dentro de la prueba, algunas fallas de la prueba dejaban cambios inesperados.

• Los trabajos paralelos chocaban. Diferentes trabajos de prueba estaban cambiando los mismos estados, lo que a menudo provocaba que uno de los trabajos fallara.

Dockerizar todo

Una solución a este problema fue dedicar un servidor back-end y una base de datos separados para cada trabajo de prueba. Este enfoque sería muy desafiante si no fuera por Docker.

Los contenedores Docker son una herramienta perfecta para crear un entorno contenido con todo lo que necesita una aplicación para ejecutarse:

• El sistema operativo correcto (o, más bien, la distribución de Linux correcta),

• las dependencias del sistema, como las bibliotecas de manipulación de imágenes, etc., y

• La versión correcta de los intérpretes de idiomas (Python, Node, etc.) o servidores de bases de datos.

Base de datos

Para su prueba, puede preparar un contenedor de base de datos dedicado que viene con datos de prueba predecibles. De esta forma, podrá reproducir exactamente el punto de partida en cada ejecución E2E, lo que hará que sus pruebas sean más estables.

Puede usar diferentes etiquetas para su imagen de Docker, para el control de versiones de la base de datos de prueba. La misma base de datos de prueba también se puede utilizar en un entorno de desarrollo. Para las pruebas manuales en desarrollo, necesita entidades de ejemplo similares a las de las pruebas automatizadas.

back-end

Si ya usó Docker para implementar su backend, será bastante fácil reutilizar la misma imagen para ejecutar su E2E. En mi equipo, implementamos un backend como contenedores y proporcionamos las URL y las credenciales de la base de datos como variables de entorno.

La misma versión del contenedor puede implementarse en producción o usarse en integración continua (CI) para ejecutar pruebas: cada entorno proporciona los valores correctos para conectarse a la base de datos.

Interfaz

En función de su estrategia de implementación, puede realizar una de las siguientes acciones:

1. Usa los contenedores que creas como parte de la construcción del frontend.

   
   

2. Obtenga los archivos compilados y asegúrese de que estén disponibles a través de HTTP para las pruebas.

En nuestro caso, usamos la opción 2: implementamos la aplicación como archivos estáticos, por lo que simplemente creamos un contenedor dedicado para servir los archivos creados durante las ejecuciones del trabajo E2E.

Servicios de trabajo en GitLab

Usamos GitLab como plataforma para ejecutar nuestro CI. Cada trabajo en GitLab se ejecuta dentro de un contenedor con una imagen de su elección. Además del contenedor principal, puede definir servicios : contenedores adicionales que se ejecutan junto con sus pruebas. La configuración es tan fácil como:

 <job-name>: services: - name: <image> alias: <container-url>

Las opciones disponibles son similares a las que tiene en Docker Compose, pero son más limitadas.

Un problema en la configuración de GitLab es establecer la variable FF_NETWORK_PER_BUILD en 1 si desea permitir que los servicios accedan entre sí durante la ejecución de la prueba.

Considere los datos ad hoc para el aislamiento en el trabajo

En algún momento, estábamos ejecutando todas las pruebas en paralelo dentro de un trabajo. En ese momento, era necesario aplicar un aislamiento aún más fuerte: cada prueba usaba el mismo backend y la misma base de datos.

Para solucionar este problema, actualizamos nuestras pruebas para que dependan principalmente de los datos aleatorios que inyectamos justo dentro de la sección before de las pruebas. Esto permitió que las pruebas se ejecutaran sin verse afectadas por otros cambios que ocurrían en otros subprocesos.

Este enfoque puede ser un poco complicado al principio, pero puede tener sentido según las circunstancias.

Limpiar después de cada prueba

Aunque comenzamos una nueva base de datos para cada trabajo de prueba, todavía estamos tratando de hacer que nuestras pruebas dejen la aplicación en el mismo estado en que la encontraron. Tal vez sea un remanente del período en el que estábamos ejecutando pruebas en un entorno compartido.

Ya no es crucial, pero aún puede ayudar durante el desarrollo de la prueba en los siguientes casos:

• Cuando ejecuta solo una prueba, por lo que el estado que encuentra la prueba no es diferente de cuando ejecuta todas las pruebas en el archivo.

• Cuando vuelve a ejecutar la misma prueba localmente una y otra vez, para que la base de datos no se vea afectada por las ejecuciones anteriores

Servicio externo simulado

Hay casos en los que trasladar los servicios a un contenedor no es una opción. Por ejemplo:

• Si hay servidores externos que la aplicación usa directamente o a través de algún servidor proxy, o

• Posee servidores que no se pueden ejecutar dentro de un contenedor debido a problemas técnicos.

En ambos casos, para aislar las ejecuciones de prueba, puede simular las solicitudes que van a esos servicios. Esto evitará que los servicios externos impredecibles afecten los resultados de su prueba. Una desventaja de este enfoque es que sus pruebas se desconectarán del contexto en el que operan sus aplicaciones.

Con los simulacros implementados, sus pruebas no detectarán casos cuando los cambios en esos servicios afecten su aplicación.

Sigue aprendiendo

Si está interesado en obtener más información sobre las pruebas u otros temas relacionados con la programación, puede registrarse aquí para recibir actualizaciones cuando publique contenido relacionado.