De frágil a blindada

Los costos y el tiempo de CI/CD, ya que los pipelines de la aplicación se componen en su mayoría de estas pruebas.

Tipos de pruebas de aplicaciones

Flakiness de las pruebas

Cobertura de código

Mocks y fakers

Pipelines de CI/CD

Sirve a una API.

Utiliza AWS DynamoDB como base de datos principal.

Todas las pruebas utilizaban un archivo utils.py global para hacer mocking, que resultó ser muy complejo de mantener a medida que crecía. Además, las pruebas eran difíciles de comprender porque los mocks se producían en otro lugar.

Las pruebas existían en un directorio separado del código fuente de la aplicación. Mientras que este último se encontraba en integrates/back/integrates, el código de pruebas se encontraba en integrates/back/test/unit. Esto afectaba nuestra experiencia de desarrollo, ya que nos obligaba a cambiar constantemente entre dos directorios diferentes.

Las pruebas se escribían utilizando pytest. Esto permitía a los desarrolladores escribir pruebas de muchas formas distintas, lo que afectaba la estandarización y aumentaba la carga cognitiva.

Todas las pruebas compartían una base de datos DynamoDB común que se ejecutaba en localhost y obtenía sus datos de un archivo database-design.json. Esto introducía flakiness, ya que a veces algunas pruebas cambiaban datos que otras utilizaban, provocando el fallo de estas últimas. Además, esta dependencia de localhost afectaba significativamente la velocidad de las pruebas debido a la lentitud de la inicialización de la base de datos.

En un intento de mitigar el flakiness que se produce cuando todas las pruebas comparten una base de datos común, las pruebas se dividieron en dos categorías:

Este enfoque conseguía hacer frente al flakiness hasta cierto punto, ya que al menos se separaban las pruebas que no modificaban la base de datos. Sin embargo, no solucionaba el problema de fondo: las pruebas compartiendo datos.

Los desarrolladores tenían que esperar a que terminara todo el conjunto de pruebas para conocer la cobertura del código. Esto era especialmente doloroso debido al hecho de que el pipeline de CI/CD fallaba si la cobertura era inferior a un umbral especificado, pero los desarrolladores solo podían validar esto después de ejecutar todo.

Las pruebas podían conectarse a Internet y comunicarse con servicios externos, lo que introducía más flakiness.

Difíciles de entender y replicar debido a la excesiva libertad dada a los desarrolladores y a tener mocks y datos globales.

Flaky debido a los datos compartidos por las pruebas de forma global.

Como había una prueba por API endpoint, rápidamente acabamos teniendo cientos de pruebas, lo que hizo que el pipeline de CI/CD creciera demasiado y los costos aumentaran.

Los mocks dejaron de ser globales, obligando a los desarrolladores a escribir mocks específicos para cada prueba. Esto mejoró la simplicidad y mantenibilidad de las pruebas.

Las pruebas existían en un directorio separado del código fuente de la aplicación. Mientras que este último se encontraba en integrates/back/integrates, el código de prueba se encontraba en integrates/back/test/functional. Esto afectaba nuestra experiencia de desarrollo, ya que nos obligaba a cambiar constantemente entre dos directorios distintos.

DynamoDB pasó a ser local para cada prueba, significando la desaparición del flakiness causado por las pruebas que modificaban los datos utilizados por otras.

Aunque cada prueba tenía su propia base de datos durante el tiempo de ejecución, todas compartían datos genéricos en un archivo conftest.py. Esto provocaba flakiness, ya que una prueba podía adaptar los datos genéricos en función de sus necesidades específicas y, por tanto, romper otras pruebas.

Las pruebas seguían requiriendo que DynamoDB se ejecutara en localhost, lo que afectaba en gran medida la velocidad debido a la inicialización de la base de datos.

A medida que crecía el número de pruebas, el hecho de que cada una de ellas utilizara su propia DynamoDB en localhost aumentaba considerablemente la cantidad total de tiempo que dedicábamos a inicializar y poblar las bases de datos, lo que reducía significativamente la velocidad y aumentaba los costos del pipeline de CI/CD.

Como DynamoDB estaba vinculada a un puerto en localhost, solo podía funcionar una base de datos en un momento dado, lo que obligaba a los desarrolladores a ejecutar solo una prueba a la vez, lo que reducía enormemente la velocidad del equipo.

Las pruebas podían conectarse a Internet y comunicarse con servicios externos, lo que introducía más flakiness.

Más fáciles de entender, ya que cada prueba tenía mocks locales y se centraba en un API endpoint específico.

Menos flaky, ya que cada prueba tenía su propia base de datos.

Las pruebas eran flaky debido a las condiciones de carrera causadas por los datos de prueba compartidos y por tener acceso a Internet.

Las pruebas se encuentran en el mismo directorio que el código fuente de la aplicación, lo que mejora la experiencia de desarrollo al permitirnos encontrar fácilmente las pruebas para archivos o funciones específicos. Esto también permite a los desarrolladores adoptar mejores prácticas, como el desarrollo basado en pruebas (Test Driven Development, TDD).

Los desarrolladores pueden escribir pruebas para cualquier cosa, incluidas funciones específicas y API endpoints. Por lo tanto, podemos migrar todas las pruebas de arquitecturas anteriores a esta.

Implementa un módulo de pruebas que estandariza la forma de escribir pruebas, las cuales son considerablemente más fáciles de entender cuando se siguen patrones comunes.

El uso de import-linter prohíbe a los desarrolladores importar librerías como pytest y unittest, obligándolos a utilizar únicamente utilidades proporcionadas por el módulo de pruebas. Esto aumenta significativamente la estandarización de las pruebas.

Implementa fakers para que los desarrolladores puedan describir parcialmente las entidades de la base de datos, haciendo que la declaración de datos para cada prueba sea mucho más cómoda y mejorando la experiencia de los desarrolladores.

Las pruebas ya no pueden conectarse a Internet ni comunicarse con servicios externos, evitando flakiness.

Proporciona una forma estándar y declarativa para que los desarrolladores añadan datos a las pruebas, mejorando su experiencia.

Ofrece a los desarrolladores una forma de declarar fácilmente mocks dentro de las pruebas, lo que facilita su comprensión.

Implementa Moto, una librería que permite simular servicios de AWS como DynamoDB. Esto hace que las pruebas se ejecuten a gran velocidad al instanciar una base de datos de DynamoDB en memoria dentro del contexto de Python de cada prueba.

Como las bases de datos existen en el contexto de Python, ya no están vinculadas a un puerto en localhost, lo que permite a los desarrolladores ejecutar pruebas simultáneamente, aumentando aún más la velocidad.

Introduce un archivo de cobertura para cada módulo de la aplicación, lo que permite a los desarrolladores ejecutar simultáneamente todas las pruebas de un módulo determinado y conocer al instante los resultados de la cobertura del código, mejorando enormemente la experiencia y la velocidad de desarrollo.

Disminuye el tamaño del pipeline de CI/CD al pasar de un enfoque de un-job-por-prueba a uno de un-job-por-módulo, lo que reduce considerablemente los costos de CI/CD.

Estándar, ya que los desarrolladores deben utilizar el módulo de pruebas especialmente diseñado para nuestras necesidades.

Menos flaky, ya que cada prueba utiliza sus propios datos y mocks y no puede conectarse a Internet.

Escalable, ya que el número de jobs de CI/CD es igual al número de módulos de la aplicación.

Haz que tus pruebas coexistan con el código de la aplicación, ya que esto permite a los desarrolladores adoptar buenas prácticas como TDD y mejora la navegación.

Si estás construyendo una gran aplicación que necesitará cientos de pruebas, en lugar de utilizar directamente librerías de pruebas de propósito general como pytest o unittest, céntrate en crear tu propio enfoque de pruebas que reutilice funcionalidades críticas de esas librerías (p. ej., un wrapper o un módulo de pruebas). Luego, utiliza import-linter para exigir a los desarrolladores emplear ese enfoque. Esto garantizará la coherencia de tus pruebas y ayudará considerablemente a los desarrolladores a mantenerlas en el largo plazo.

Usa librerías que simulen servicios core, como Moto, en lugar de servir esos componentes en localhost para que así las pruebas se ejecuten mucho más rápido.

Evita los estados globales para tus pruebas tanto como sea posible (datos, mocks, etc.), ya que introducen flakiness. Utiliza librerías como Moto para proporcionar un estado local para cada prueba.

Prohíbe que tus pruebas lleguen a Internet para así evitar flakiness.

Migrar todas las pruebas de nuestras arquitecturas previas a esta con el fin de dejar obsoletos los flujos antiguos y mantener las cosas simples. Puedes encontrar más información al respecto aquí.

Hacer que esta arquitectura soporte otros componentes críticos para el monolito, tales como AWS S3, AWS OpenSearch y AWS lambda. De esta forma, los desarrolladores podrán simular fácilmente otras partes del monolito manteniendo todos los beneficios de la arquitectura actual. Más detalles aquí.

Esta arquitectura se hizo específicamente para el monolito de la plataforma de Fluid Attacks, por lo que está acoplada a él, lo que nos impide utilizarla en otras aplicaciones que podrían beneficiarse de algunas de sus propiedades. Una de las cosas que pensamos hacer a largo plazo es desacoplar el modelo de datos de Fluid Attacks del monolito para que otras aplicaciones también puedan utilizarlo. El primer paso que daremos en esa dirección se describe aquí.

Juan Diaz, por implementar partes centrales de la nueva arquitectura como CLI, fakers, Moto, etc.