DEV Community: Alex Castells

Consentimientos sobre cookies

Alex Castells — Thu, 03 Jun 2021 08:38:22 +0000

¿Sabes qué es un CMP?

Seguro que en tu día a día navegando por internet has interactuado con más de uno 😉

Con Ivan Martinez @ivanmlaborda os contamos de dónde sale la necesidad de tener uno, qué es y cómo trabajamos en Adevinta Spain para implantar nuestro CMP para el tratamiento de consentimientos sobre cookies.

👋 Alex Castells

👋 Ivan Martinez

🍪 ¿En qué consiste el proyecto de consentimientos sobre cookies?

🚀 ¿Cómo ha impactado al equipo de producto de Ivan?

💡 ¿Qué es el CMP?

🔧 ¿Cúales fueron los principales retos técnicos?

📈 ¿Queda algo por hacer?

Usando AWS S3 en local con LocalStack

Alex Castells — Thu, 11 Mar 2021 11:57:08 +0000

En ocasiones nuestros servicios deben integrarse con infraestructuras difíciles de reproducir en local para el desarrollo o para ejecutar los tests, y AWS es un ejemplo de ello.

Para los tests, a veces con mocks puede bastar para sortear el problema.

Pero, para probar nuestro servicio en local, deberíamos usar nuestras credenciales de AWS y conectarnos al entorno real? Y... los demás miembros del equipo?

En este post veremos qué es LocalStack y lo usaremos para hacer funcionar en local un servicio para almacenar ficheros en S3.

LocalStack bajo el lema "a fully functional local AWS cloud stack" puede ser la herramienta que necesitemos para algunos de nuestros desarrollos con los SDKs de AWS.

Dispone de una versión gratuita que nos permitirá desarrollar contra servicios como S3, SQS, DynamoDb, ...
Y otra versión de pago con servicios como CloudFront, Neptune, ...

ver detalle de servicios en cada versión...

Por poner un ejemplo (y código 🤓), supongamos que necesitamos una API contra la que postear imágenes que luego vamos a usar para servirlas en un entorno web.

Este es un caso de uso ideal para usar un bucket de S3 como sistema de almacenamiento y CloudFront como sistema de recuperación.

Así que... vamos a probar LocalStack 💻🚀

Nota: CloudFront forma parte de los servicios de la distribución de pago de LocalStack, así que no lo podremos probar en local sin pagar... aunque... si sabemos cómo acaba linkado un bucket de S3 como origin de una distribución de CloudFront y cómo afecta a las URL para recuperar los ficheros almacenados en S3, algo se nos va a ocurrir :)

Ejemplo

alextremp / s3-storage-service-demo

AWS S3 storage en local con LocalStack

Este proyecto es una demo para un artículo en dev.to/alextremp

Servicio de almacenamiento de ficheros a bucket de S3

Un endpoint POST para enviar un fichero a un path específico.
El servicio almacenará el fichero a un bucket de S3.
Devolverá la URL de acceso del fichero, ya sea local, de S3 o de CloudFront si se dispone.

Uso

El endpoint de ejemplo estará expuesto para POST en http://localhost:8080/storage Acepta form-data con:

file: El fichero que queremos guardar en S3
path: La ruta donde queremos guardar el fichero, relativa respecto el bucket

Ejecución en local contra LocalStack

docker-compose up -d
./gradlew bootRun

Ejecución en local contra bucket real

# active profile set to production
PROFILE="--spring.profiles.active=pro"
# your AWS access key
ACCESS="--s3-storage.accessKey="
# your AWS secret key
SECRET="--s3-storage.secretKey="
# your AWS S3 bucket

…

View on GitHub

Stack:



java, spring-boot, aws-sdk, testcontainers

Levantando S3 con docker-compose

Configuremos el servicio de localstack:

docker-compose.yml



version: '3.5'

services:
  s3-storage:
    image: localstack/localstack:0.12.5
    environment:
      # permite más servicios separados por comas
      - SERVICES=s3 
      - DEBUG=1
      - DEFAULT_REGION=eu-west-1
      - AWS_ACCESS_KEY_ID=test
      - AWS_SECRET_ACCESS_KEY=test
    ports:
      # localstack usa rango de puertos, para el ejemplo,
      # usaremos solo el de S3, mapeado en local a 14566 en un 
      # fichero docker-compose.override.yml para permitir 
      # tests con puerto dinámico
      - '4566'
    volumes:
      # inicializaremos un bucket aquí
      - './volumes/s3-storage/.init:/docker-entrypoint-initaws.d'
      # no versionado, localstack nos generará aquí el .pem 
      # para nuestras claves de acceso fake
      - './volumes/s3-storage/.localstack:/tmp/localstack'

Podemos generar un bucket al iniciar el docker-compose:

./volumes/s3-storage/.init/buckets.sh



#!/bin/bash
aws --endpoint-url=http://localhost:4566 s3 mb s3://com.github.alextremp.storage

Al ejecutar docker-compose up deberíamos ver que el cliente de AWS de la imagen de localstack ha generado el bucket que le hemos indicado en el script de inicialización:

Interactuando con el bucket

Para el artículo me interesa explicaros sólo unos puntos concretos del código de ejemplo, para que veamos cómo podemos hacerlo funcionar en local con LocalStack y en entorno productivo con AWS.

Tomando como referencia el repositorio que usará el SDK de AWS para S3 de cara a guardar un fichero (en realidad el InputStream de un recurso recibido en un POST multipart):



  public S3ResourceRepository(S3Client s3Client,
                              S3ResourceRepositoryOptions repositoryOptions,
                              DestinationFactory destinationFactory) {
    this.s3Client = s3Client;
    this.repositoryOptions = repositoryOptions;
    this.destinationFactory = destinationFactory;
  }

  @Override
  public Destination save(StreamableResource streamableResource, ResourceOptions resourceOptions) {
    PutObjectRequest.Builder requestBuilder = PutObjectRequest.builder()
          // the target bucket
          .bucket(repositoryOptions.getBucket())
          // the target path in the bucket
          .key(resourceOptions.getPath());

    // setting the content-type makes it web-friendly when being read
    requestBuilder.contentType(URLConnection.guessContentTypeFromName(resourceOptions.getPath()));
    // it's highly recommendable to specify the cache-control for presupposed repetitive reads, specially if it's combined with CloudFront
    requestBuilder.cacheControl(String.format("public, max-age=%s", resourceOptions.getMaxAge()));

    if (!repositoryOptions.hasOriginReference()) {
      // when needed to be read directly from S3, no need if it's a bucket linked to CloudFront
      requestBuilder.acl(ObjectCannedACL.PUBLIC_READ);
    }

    PutObjectRequest objectRequest = requestBuilder.build();
    s3Client.putObject(objectRequest, RequestBody.fromInputStream(streamableResource.stream(), streamableResource.contentLength()));

    return destinationFactory.create(resourceOptions.getPath());
  }

En realidad, para que el servicio sea funcional en local igual que en producción (e incluso si tuviéramos un entorno intermedio de desarrollo o pre-producción en la nube), lo más interesante son las opciones que podemos necesitar modificar para el funcionamiento del repositorio en cada uno de los entornos.



@Data
@FieldDefaults(level = AccessLevel.PRIVATE)
@Accessors(chain = true)
@NoArgsConstructor
public class S3ResourceRepositoryOptions {
  String region;
  String accessKey;
  String secretKey;
  String bucket;
  String endpoint;
  String originFor;

  public Boolean hasCustomEndpoint() {
    return StringUtils.isNotBlank(endpoint);
  }

  public Boolean hasOriginReference() {
    return StringUtils.isNotBlank(originFor);
  }
}

S3 Endpoint Override



# application-dev.yml
s3-storage:
  endpoint: http://localhost:14566

Con respecto a la opción hasCustomEndpoint, en local, tanto para podernos comunicar con S3 al guardar un fichero (por defecto, tipo s3://BUCKET/PATH), como para luego poderlo recuperar vía HTTP (por defecto, tipo https://s3-REGION.amazonaws.com/BUCKET/PATH), necesitamos modificar el endpoint que expone S3 en LocalStack y usarlo en el servicio para comunicarnos con él.

En LocalStack ya lo hemos hecho en el script de inicialización en docker-compose mediante aws --endpoint-url=http://localhost:4566 ...
En la creación del cliente de S3, debemos ligarlo mediante la opción endpointOverride:



@Configuration
@ComponentScan("com.github.alextremp.storage.infrastructure.aws")
public class AwsConfiguration {

  @Bean
  @ConfigurationProperties(prefix = "s3-storage")
  public S3ResourceRepositoryOptions s3ResourceRepositoryOptions() {
    return new S3ResourceRepositoryOptions();
  }

  @Bean
  public S3Client s3Client(S3ResourceRepositoryOptions s3ResourceRepositoryOptions) {
    S3ClientBuilder s3ClientBuilder = S3Client.builder()
          .credentialsProvider(StaticCredentialsProvider.create(AwsBasicCredentials.create(
                s3ResourceRepositoryOptions.getAccessKey(),
                s3ResourceRepositoryOptions.getSecretKey()
          )))
          .region(Region.of(s3ResourceRepositoryOptions.getRegion()));

    if (s3ResourceRepositoryOptions.hasCustomEndpoint()) {
      s3ClientBuilder.endpointOverride(URI.create(s3ResourceRepositoryOptions.getEndpoint()));
    }
    return s3ClientBuilder.build();
  }
}

Esto nos permitirá guardar correctamente ficheros en localhost:

Así como recuperarlos vía HTTP:

Habilitando salida en CloudFront para PROD

Si usáramos este servicio para interactuar con un bucket real, sin CloudFront, p.ej.:



# application-pro.yml
s3-storage:
  bucket: a.dcdn.es

  # add the accessKey and secretKey config...

La URL que necesitaríamos generar para poder acceder vía HTTPS al mismo recurso en S3, sería algo así:
https://s3-eu-west-1.amazonaws.com/a.dcdn.es/demo/demo-image.png

Sin embargo, si tuviéramos ese bucket mapeado como origen en una distribución de CloudFront, p.ej.:

Aunque no podamos probar CloudFront en LocalStack, podríamos configurar el servicio para que generara las URL necesarias para la salida via CloudFront:



# application-pro.yml
s3-storage:
  bucket: a.dcdn.es
  originFor: a.dcdn.es

  # add the accessKey and secretKey config...

Para que esto sea así, y para terminar con el ejemplo de código, sólo necesitaremos que nuestro servicio sea capaz de generar las URL según las propiedades del storage:



@Component
public class AwsDestinationFactory implements DestinationFactory {

  private static final String HTTPS_PROTOCOL = "https://";
  private static final String AWS_S3_DOMAIN_TEMPLATE = "s3-%s.amazonaws.com";

  private final S3ResourceRepositoryOptions options;

  public AwsDestinationFactory(S3ResourceRepositoryOptions options) {
    this.options = options;
  }

  @Override
  @SneakyThrows
  public Destination create(String path) {
    StringBuilder rootBuilder = new StringBuilder();
    if (options.hasOriginReference()) {
      rootBuilder.append(HTTPS_PROTOCOL)
            .append(options.getOriginFor());
    } else if (options.hasCustomEndpoint()) {
      rootBuilder.append(options.getEndpoint())
            .append(Destination.SEPARATOR)
            .append(options.getBucket());
    } else {
      rootBuilder.append(HTTPS_PROTOCOL)
            .append(String.format(AWS_S3_DOMAIN_TEMPLATE, options.getRegion()))
            .append(Destination.SEPARATOR)
            .append(options.getBucket());
    }
    return new Destination(rootBuilder.toString(), path);
  }
}

🚀🚀

Conclusiones

Desde mi punto de vista, cuando hay código en producción cuya ejecución no es reproducible en local / automatizable en tests, tenemos dos opciones: hacerlo reproducible en local, o cruzar los dedos 😬

Pero como necesitamos los dedos para teclear, LocalStack, junto con Docker Compose y Test Containers pueden ayudarnos a solventar los problemas de infraestructura para la ejecución local cuando trabajamos integrados con servicios de AWS, de modo que nosotros podamos focalizarnos en el código más que en el entorno de ejecución.

Si algún día hacéis algo con S3, sois libres de copy-pastear lo que necesitéis :)

alextremp / s3-storage-service-demo

Inversión de Control en Arquitectura Frontend

Alex Castells — Tue, 26 Jan 2021 13:39:41 +0000

DDD, arquitectura hexagonal, SOLID, IoC...

Backend? Frontend? O simplemente principios del software para la programación orientada a objetos?

En este post daremos un paseo por la arquitectura del software, como método de diseño agnóstico al frontend y al backend para ver las similitudes entre ambos contextos.

Eso sí, usaré la inversión de control como referencia, dado que siendo quizá el principio que más fácil de ver es cómo habilita el diseño de software modular, es a la vez el que más frameworks "estandarizados" tiene cuando hablamos de backend (p.ej. Spring), pero el que parece tener menos en frontend.

También aprovecharé al final para introduciros a brusc, una pequeña librería que desarrollé hará poco más de un año para habilitar la inyección de dependencias en proyectos de ES6.

Introducción a clean architectures

Clean architectures

Muchos de los conceptos a la hora de hablar de clean architectures, best practices, principios de diseño, ... se basan en solucionar lo mismo: cómo organizar los distintos componentes de nuestro software en capas para maximizar su cohesión y minimizar el acoplamiento.

A la hora de representar el comportamiento de una aplicación, cómo se puede interactuar con ella, qué sucede con las interacciones y cómo navegan los datos, a mi personalmente me gusta hablar de:

Actores: quién inicia las interacciones (usuario, tiempo, ...) y para qué.
Interfaces de acceso: de qué disponen los actores para interactuar (UI, CLI, ...).
Infraestructura de acceso: cómo debe habilitarse un acceso para una interfaz concreta (comandos, controladores, ...)
Casos de uso (o servicios de aplicación): cómo permitimos la interacción del exterior hacia nuestro dominio para consultarlo o manipular su estado.
Dominio: donde reside la abstracción de nuestro negocio (entidades de negocio, definiciones de repositorios, ...) para que los casos de uso puedan llevar a cabo su cometido.
Infraestructura de salida: cómo debe habilitarse una salida concreta hacia otro sistema que nos permita la recuperación y almacenaje del estado de nuestro dominio (APIs HTTP, BBDD, ...)

Hay muchas otras formas de expresarlo, pero la idea general de todas ellas es que desde la concreción de infraestructura hacia la abstracción de la lógica de negocio (dominio), hay una flecha unidireccional de acceso por las diferentes capas, para evitar que los componentes lógicos se vean afectados por cambios de infraestructura (The Dependency Rule].

Por ejemplo, nuestro dominio debería ser el mismo, así como los casos de uso que se exponen para habilitar la interacción con él, independientemente de si sustituimos el acceso a la aplicación mediante línea de comandos por un acceso mediante UI.

Una forma de representar esto puede ser mediante arquitectura hexagonal

Frontend, Backend, puede ser lo mismo desde la perspectiva OOP

Para empezar a hablar de estos conceptos aplicados al frontend, veamos una representación muy esquemática de arquitectura hexagonal para una aplicación "típica" de backend accesible vía API:

Suponiendo que el servicio fuera para poder realizar búsquedas de libros, el "foco" del desarrollador sería:

Definir el dominio que represente la lógica esperada de este servicio (domain), p.ej: Book como entidad, BookRepository como representación de las operaciones necesarias para recuperarlo.
Definir los casos de uso para exponer las interacciones sobre este dominio al exterior (application), p.ej: SearchBooksUseCase
Definir la recuperación o almacenaje concretos (infrastructure), p.ej: disponemos de una base de datos MySql y deberíamos implementar las operaciones de la abstracción de dominio BookRepository como por ejemplo, JdbcBookRepository o MySqlBookRepository
Definir los controladores HTTP del servicio para habilitar los accesos vía API (infrastructure), p.ej: BookController

Y aquí ya saldría un problema si tenemos en cuenta la (Dependency Rule]: ¿Cómo puede el caso de uso recuperar los libros de la base de datos sin saber que el repositorio de libros debe acceder a una base de datos? ¿Cómo recibe la implementación concreta para MySql?

Pues precisamente aquí es donde entra en juego la inversión de control.

Si nuestro caso de uso depende de un repositorio para hacer su labor, siguiendo la D de los principios SOLID, el caso de uso SearchBooksUseCase debe depender de una abstracción (BookRepository), no de una concreción (MySqlBookRepository), dado que el caso de uso no debería verse afectado si el día de mañana cambiamos MySql por Oracle, o incluso si cambiamos el almacenaje de libros a una API de terceros accesible por HTTP en lugar de por JDBC.

Podríamos representar la inversión de control de dependencias así:

Y para lograrlo, podríamos implementar esta inversión de control con el patrón de Inyección de Dependencias.

Otra forma de lograrlo es mediante el patrón Service Locator

La de inyección de dependencias basada en framework de infraestructura consiste en un contenedor de dependencias capaz de proveer de una implementación concreta a partir de una abstracción (o declaración) y un inyector de dependencias que usará esa funcionalidad del contenedor para proveer al cliente esas dependencias ocultándole la implementación.

De forma esquemática, lo que acaba sucediendo es esto:

Y con todo lo anterior en mente... xD, ahora sí: toca hablar de cómo aplica el mismo concepto en el desarrollo de frontend.

Supongamos que queremos desarrollar la UI web de un sistema de gestión de libros.

Supongamos además que no es sólo la UI entendida como componentes HTML y CSS, sino que tenemos asociada una lógica de negocio y debemos desarrollar una serie de casos de uso que sólo aplican al entorno web.

Si aplicáramos las mismas metodologías y terminología para el desarrollo de software al que hacía referencia cuando describía el sistema para ser accedido como API de backend, volveríamos a hablar de dominio, casos de uso, infraestructura de acceso, infraestructura de salida, ... por lo que esquematizando el mismo concepto con arquitectura hexagonal veríamos algo como:

Sólo que en este caso, por ejemplo, veríamos que la infraestructura necesaria para poder recuperar los libros debería ser representada con un acceso vía HTTP a la API de backend, y podríamos representar el caso de uso de búsqueda de libros hasta su repositorio concreto así:

De este modo, nuestra implementación de componentes de UI no tiene que saber nada sobre cómo está implementada internamente la aplicación JS de gestión de libros, sólo debe conocer qué accesos se le han habilitado para poder interactuar con ella, y esos accesos no sufrirán cambios si nuestra tecnología para accederlos es una UI en React, en Angular, en Vue, o un test.

Inversión de control en Javascript

Ya sea en ES6 o en Typescript, el concepto es el mismo.
Yo me centraré en ES6 porque es lo que suelo usar en el día a día, y para hablaros de brusc, pero podéis echarle un ojo a inversify que es también un framework muy potente orientado a proyectos Typescript.

Para entender mejor la inversión de control, os pongo primero un ejemplo de lo que no es, para que veamos qué problemas supone y cómo lo evolucionamos a un mejor diseño, partiendo de la base de la librería para la gestión de libros.

Supongamos que queremos cumplir este expect:

it('should find a book', async () => {
    const givenQuery = 'Sin Noticias De Gurb'
    const books = await Books.searchBooks({query: givenQuery})
    expect(
      books.filter(book => book.title === givenQuery).length
    ).to.greaterThan(0)
})

Podríamos implementar la solución así:

simplificado a fichero único y sin entidad de dominio

class Books {
  constructor() {
    this._searchBooksUseCase = new SearchBooksUseCase()
  }

  searchBooks({query}) {
    return this._searchBooksUseCase.execute({query})
  }
}

class SearchBooksUseCase {
  constructor() {
    this._bookRepository = new HttpOpenLibraryBookRepository()
  }

  execute({query}) {
    return this._bookRepository.find({query})
  }
}

import axios from 'axios'
class HttpOpenLibraryBookRepository {
  constructor() {
    this._libraryApi = 'http://openlibrary.org'
  }

  find({query}) {
    return axios
      .get(`${this._libraryApi}/search.json?q=${query}`)
      .then(response => response.data.docs)
  }
}

const books = new Books()
export default books

Aunque el test pasaría, esto tiene varias que me harían llorar:

Cada clase se está responsabilizando de la construcción de sus dependencias.
Todo depende de concreciones.
No es posible sustituir una implementación por una extensión de la misma, ¿cómo testearíamos el caso de uso individualmente sin poder reemplazar la implementación HTTP del repositorio por p.ej. un stub?
¿Y si tuviéramos que implementar un nuevo caso de uso que dependiera del mismo repositorio, lo inicializaríamos de nuevo? ¿Y si algún día quisiéramos cambiar OpenLibrary por otra API, en cuántos casos de uso deberíamos reemplazar el repositorio?

Deberíamos iterar esta solución, aunque evidentemente es mejor que si usáramos directamente un fetch desde un componente de UI, dado que a medida que el proyecto tuviera más necesidades, estos problemas se multiplicarían y cada vez se haría menos extensible y menos mantenible.

Otra opción: Aplicando la inversión de control a mano

class Books {
  constructor({searchBooksUseCase}) {
    this._searchBooksUseCase = searchBooksUseCase
  }

  searchBooks({query}) {
    return this._searchBooksUseCase.execute({query})
  }
}

class SearchBooksUseCase {
  constructor({bookRepository}) {
    this._bookRepository = bookRepository
  }

  execute({query}) {
    return this._bookRepository.find({query})
  }
}

import axios from 'axios'
class HttpOpenLibraryBookRepository {
  constructor() {
    this._libraryApi = 'http://openlibrary.org'
  }

  find({query}) {
    return axios
      .get(`${this._libraryApi}/search.json?q=${query}`)
      .then(response => response.data.docs)
  }
}

class BooksInitializer {
  static init() {
    const bookRepository = new HttpOpenLibraryBookRepository()
    const searchBooksUseCase = new SearchBooksUseCase({bookRepository})
    return new Books({searchBooksUseCase})
  }
}

const books = BooksInitializer.init()
export default books

Esto ya empezaría a coger otra forma:

El caso de uso no conoce la implementación del repositorio.
Esta implementación podría ser sustituida en un test unitario del caso de uso o por una implementación distinta en el "initializer", y el caso de uso no se vería afectado.

Aún así, si el proyecto empezara a crecer en casos de uso y repositorios, nos podríamos encontrar con los siguientes problemas:

Todas las dependencias deben ser inicializadas en un orden específico, añadiendo complejidad a futuros cambios a medida que el proyecto crece.
Si el caso de uso de repente necesitara una nueva dependencia, se debería sincronizar la inicialización también en el "initializer", y podría provocar un reordenamiento de otras dependencias.

Y aquí podría entrar la inyección de dependencias mediante framework, como por ejemplo usando brusc:

const inject = key => inject.provide(key)

const TYPES = {
  searchBooksUseCase: 'searchBooksUseCase',
  bookRepository: 'bookRepository'
}

class Books {
  constructor({searchBooksUseCase = inject(TYPES.searchBooksUseCase)} = {}) {
    this._searchBooksUseCase = searchBooksUseCase
  }

  searchBooks({query}) {
    return this._searchBooksUseCase.execute({query})
  }
}

class SearchBooksUseCase {
  constructor({bookRepository = inject(TYPES.bookRepository)} = {}) {
    this._bookRepository = bookRepository
  }

  execute({query}) {
    return this._bookRepository.find({query})
  }
}

import axios from 'axios'
class HttpOpenLibraryBookRepository {
  constructor() {
    this._libraryApi = 'http://openlibrary.org'
  }

  find({query}) {
    return axios
      .get(`${this._libraryApi}/search.json?q=${query}`)
      .then(response => response.data.docs)
  }
}

import Brusc from 'brusc'
class BooksInitializer {
  static init() {
    Brusc.define(inject)
      .singleton(TYPES.searchBooksUseCase, () => new SearchBooksUseCase())
      .singleton(TYPES.bookRepository, () => new HttpOpenLibraryBookRepository())
      .create()
    return new Books()
  }
}

const books = BooksInitializer.init()
export default books

Aunque la solución tampoco es perfecta debido a las limitaciones propias del lenguaje, que para Brusc implica requerir la definición de una función inject accesible para todos los componentes de la librería (y opcionalmente las claves para los tipos), igual que sucede con Inversify y el uso de los decoradores para la inyección, usar una librería para como Brusc nos ofrecerá varios beneficios:

Facilidad de bootstrapping de la librería, sin necesidad de tener que pensar en el orden de inicialización de instancias (pueden ser agrupadas por capas, intención, ...)
Protección frente a dependencias circulares (se lanzaría error de inicialización en lugar de quedarse en un bucle infinito)
Declaración clara de instancias en el contenedor (singletons para instancias reusables, prototipos para instancias con estado)
Posible instrumentalización de las instancias en el contenedor (ver adapters de Brusc)

Y por último pero no menos importante, en el caso concreto de Brusc:

Pensado para facilitar la implementación de tests de integración usando los inject.defaults para sustituir instancias del contenedor durante la ejecución de un test.

Pros y contras

Para terminar, teniendo en cuenta que las guías de diseño, principios, patrones y demás están ahí para darnos herramientas que nos faciliten tomar decisiones en el desarrollo, pero nunca hay una única ni mejor manera de implementar una aplicación, me gustaría comentar algunos pros y contras de aplicar arquitecturas limpias en frontend, para animaros a usarlas pero también para evitar desengaños xD

Contras

El tamaño final de la solución se verá incrementado: Si bien nos puede compensar la mantenibilidad, testabilidad, ... en proyectos grandes, introducir dependencias o hacer una separación muy granular de las capas, nos va a incrementar el tamaño del distribuible final, cosa que debemos contemplar cuando se trata de un fichero que terminará siendo descargado desde terminales móviles.
Se debe escribir más código para poder representar cada entidad, repositorio, caso de uso, ... Más código ejecutable implica más código a mantener.
Dependencia a frameworks/librerías, ya sea Brusc, inversify o cualquier otra, incluso privada, para implementar de otra manera la inversión de control.

Pros

Baja curva de aprendizaje (y mantenibilidad): aplicar una arquitectura homogénea a todos los proyectos posibles (incluso independientemente del contexto de ejecución front/back), permite a los desarrolladores adaptarse más rápidamente a cualquier proyecto OOP.
Testabilidad: se facilita la creación de tests unitarios y de integración.
Extensibilidad: se pueden realizar cambios, reemplazar componentes, ... sin afectar a todo el código.

Lo resumiría en simplicidad.

Hasta aquí llega lo que quería compartir con vosotros, así que termino el tostón por hoy, si habéis llegado hasta aquí ya me hacéis feliz ;)

Integrando TestContainers en el contexto de Spring en nuestros tests

Alex Castells — Tue, 22 Dec 2020 08:20:35 +0000

Aún me acuerdo de cómo hace muuuuchos años, en "la edad de los hierros", configurar un entorno local para desarrollar partes de plataformas complejas era un drama, y cómo se acababan configurando hosts in-house para replicar esa infraestructura externa y poder trabajar en equipo sobre la misma base.

Pero, a la hora de ejecutar tests en esas máquinas, a la que se necesitara algún cambio de versión mientras se seguía desarrollando sobre lo antiguo, o simplemente cambiar el tipo de dato de una columna de BBDD, drama otra vez, o replicarse esa máquina en local "temporalmente".

En este post os daré una pincelada a cómo podemos integrar TestContainers en el flujo de ejecución de tests con Junit5 para un servicio desarrollado con Spring Boot, dejando que sea Spring quien haga el trabajo por nosotros, aprovechándonos de las características del ciclo de vida del ApplicationContext durante la ejecución de los tests.

Para ello, integraré testcontainers con distintas soluciones sobre un proyecto demo base, y os expondré corner cases en los que esas soluciones pueden no ser operativas, teniendo en cuenta que para los tests, y entornos de CI, por lo general es [una mala práctica fijar puertos.], de modo que este post se focalizará en la ejecución de tests con infraestructuras externas levantadas en local en puertos dinámicos.
(https://www.testcontainers.org/features/networking/) From the host's perspective Testcontainers actually exposes this on a random free port. This is by design, to avoid port collisions that may arise with locally running software or in between parallel test runs.

Para darle un poco de gracia al uso de contenedores tanto para el desarrollo local como para los tests, y entender por qué usándolos podemos lograr reducir al máximo el riesgo de subir código a un entorno real cuando los tests pasan y "en local funciona", os propongo un servicio que no expondrá una API, sino que:

debe escuchar mensajes de texto emitidos por otro servicio a una cola de RabbitMQ
debe grabar esos mensajes a una base de datos PostgreSQL

A priori, un servicio muy sencillo, pero

cómo validaríamos que realmente funciona?
cómo automatizaríamos esas validaciones?

Como base, usaré este repositorio que implementa el servicio:

😑 Rama base, sin TestContainers, pero podremos probarlo haciendo hecho un docker-compose up previamente.

También, como referencia a las pruebas que comentaré por puntos al final del post, os dejo estas PR para poder ver cómo cambiaría el código base, o descargaros la rama para jugar.

😕 TestContainers integrados con JUnit
🚀 TestContainers singleton gestionados manualmente
😍 TestContainers gestionados por Spring

Pero antes de empezar, una breve intro a Docker Compose y TestContainers

Docker Compose

Hoy en día, Docker facilita y estandariza la forma en cómo los servicios de nuestras plataformas se despliegan en la nube, y Docker Compose nos facilita la vida en el entorno local, habilitándonos esos servicios de infraestructuras (bases de datos, sistemas de mensajería, ...) externas de un modo fiable.

Seguramente habréis visto en la raíz de gran cantidad de repositorios un fichero docker-compose.yml, por lo general muy fáciles de entender a primera vista, como por ejemplo:

version: '3.5'

services:

  # base de datos PostgreSQL
  message-store-db:
    # https://hub.docker.com/_/postgres
    image: postgres:13.0-alpine
    # mapeo de puertos (puerto_accesible_desde_localhost:puerto_del_servicio_en_el_contenedor)
    ports:
      - "5432:5432"
    # configuración de la imagen de docker
    environment:
      POSTGRES_USER: "demo"
      POSTGRES_PASSWORD: "p4ssw0rd"
      POSTGRES_DB: "messagestore"
    # inicialización de la base de datos 
    volumes:
      - ./.init/message-store-db/init.sql:/docker-entrypoint-initdb.d/init.sql

Con instrucciones para levantar el repositorio en local, y que con un simple comando:

docker-compose up

Tenemos la infraestructura externa, en este caso una base de datos, lista en nuestra máquina para poder operar con ella desde nuestro servicio levantado en local, o incluso en este ejemplo, conectándonos directamente a PostgreSQL con algún visor de bases de datos.

Esto nos permite validar que nuestro proyecto, que usará un driver específico para la base de datos, ejecutando sentencias o configurando opciones que quizá no están disponibles para todas las versiones de ese sistema de base de datos, funciona.

Y como podremos levantar en local la misma versión de base de datos que tengamos en entorno real, el riesgo de que no funcione ahí se reduce a mínimos.

Esto no pasaría implementando los accesos a base de datos de los tests con por ejemplo, una base de datos en memoria como H2, que por defecto no soporta PL/SQL.

Pero, si desarrollamos en local con esos servicios, mirando que nuestro servicio opera correctamente con ellos, ¿por qué no automatizar los tests de integración usando el mismo sistema y así poder ejecutar los tests tanto en nuestra máquina como en nuestro sistema de CI?

TestContainers

TestContainers es una librería Java diseñada para controlar las instancias de servicios dockerizados, enfocada a ser integrada con JUnit/Spock/... para nuestros tests de integración.

Como ejemplo de uso, la misma PostgreSQL creada con la API de TestContainers quedaría así:

PostgreSQLContainer messageStoreDbContainer =
      new PostgreSQLContainer<>("postgres:13.0-alpine")
        .withDatabaseName("message-store-db")
        .withUsername("demo")
        .withPassword("p4ssw0rd")
        .withInitScript("/.init/message-store-db/init.sql");
messageStoreDbContainer.setPortBindings(Arrays.asList("5432:5432"));

// podemos arrancar el servicio con
messageStoreDbContainer.start();

// y pararlo con
messageStoreDbContainer.stop();

Otro componente que nos ofrece, para permitirnos simular los tests con exactamente los mismos servicios que levantaríamos con el docker-compose.yml, es DockerComposeContainer

Un ejemplo de uso:

WaitStrategy postgresWaitStrategy = new WaitAllStrategy(WITH_INDIVIDUAL_TIMEOUTS_ONLY)
  .withStrategy(Wait.forListeningPort())
  .withStrategy(Wait.forLogMessage(".*database system is ready to accept connections.*", 1));

DockerComposeContainer dockerComposeContainer =
  new DockerComposeContainer(new File("docker-compose.yml"))
    .withLocalCompose(true)
    .waitingFor("message-store-db", postgresWaitStrategy);

dockerComposeContainer.start();

Veréis que aquí se usa una funcionaliad opcional de la API de DockerComposeContainer para poder definir cómo debe esperarse el componente para decir que está ready hasta que el servicio "message-store-db" del "docker-compose.yml" esté ready.

Por defecto, se esperaría 60 segundos a que el servicio tuviera el puerto expuesto y listo para aceptar conexiones.

Ahora le estamos indicando que a parte de esperar al puerto, se espere también a que PostgreSQL, en su proceso de inicialización, haya sacado esa traza de log indicando que está completamente ready

Para el caso propuesto, dado que los tests deben validar la integración con los servicios definidos en el docker-composer, usaré DockerComposeContainer.

Y en realidad, para la mayoría de casos es el único que vamos a necesitar.

Así que al lío :)

¿Cómo lo integramos en nuestros tests?

Nos tenemos que preguntar: ¿Los servicios de infraestructura externa deben cambiar para distintos escenarios de test, independientemente del contexto de Spring?

O por lo contrario, ¿Los servicios de infraestructura externa deben tener el mismo ciclo de vida que el contexto de Spring?

Para ejemplificar las pruebas de integración de TestContainers en JUnit y SpringBoot, encontraréis este test sencillo en la rama master del proyecto demo.

@SpringBootTest
@Sql("/fixtures/message-store-db/clean.sql")
class ApplicationTest {

  @Autowired
  private RabbitTemplate rabbitTemplate;

  @Autowired
  private MessageMapper messageMapper;

  @Value("${mq-server.routing.exchange}")
  private String demoExchange;

  @Value("${mq-server.routing.message.queue.dispatched}")
  private String messageDispatchedQueue;

  @Test
  void shouldSaveEmittedMessage() {
    String givenText = "hello world";
    rabbitTemplate.convertAndSend(demoExchange, messageDispatchedQueue, givenText);

    await().atMost(Duration.ONE_SECOND)
          .alias(format("message [%s] has been saved", givenText))
          .until(() -> messageMapper.selectOneByText(givenText).isPresent());
  }

}

Nota: para los que no la conozcáis, await es un operador de awaitility, muy útil para validación de resultados en procesos asíncronos.

Ciclo de vida controlado por JUnit

Empecemos con la chicha :)

código de referencia de este punto

Si miramos la documentación para integrar TestContainers con JUnit, la integración básica es muy sencilla: mediante anotaciones de la propia librería, se habilita la gestión de arranque y parada de los servicios dockerizados, y éstos pueden exponer los puertos que ha podido coger por estar libres.

⚠️ Pero ojo, nosotros necesitamos ciertas propiedades en el contexto de Spring, o dicho de otra manera, ¿cómo asignaremos los puertos designados a nuestras conexiones de base de datos y MQ?

En este caso, usaremos la capacidad de Spring de recoger propiedades de System, pudiendo configurar nuestros tests así:

@SpringBootTest
@Testcontainers
abstract class AbstractIntegrationTest {

  private static final String MESSAGE_STORE_DB_SERVICE = "message-store-db";
  private static final Integer MESSAGE_STORE_DB_PORT = 5432;
  private static final String SPRING_MESSAGE_STORE_DB_PORT = "message-store-db.port";

  private static final String MQ_SERVER_SERVICE = "mq-server";
  private static final Integer MQ_SERVER_PORT = 5672;
  private static final String SPRING_MQ_SERVER_PORT = "mq-server.port";


  @Container
  private static DockerComposeContainer dockerServices =
        new DockerComposeContainer<>(new File("docker-compose.yml"))
              .withLocalCompose(true)
              .withExposedService(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)
              .withExposedService(MQ_SERVER_SERVICE, MQ_SERVER_PORT);

  @BeforeAll
  public static void beforeAll() {
    setProperty(SPRING_MESSAGE_STORE_DB_PORT, valueOf(dockerServices.getServicePort(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)));
    setProperty(SPRING_MQ_SERVER_PORT, valueOf(dockerServices.getServicePort(MQ_SERVER_SERVICE, MQ_SERVER_PORT)));
  }
}

En este caso, sólo que nuestro ApplicationTest extienda esta abstracción, al ejecutarse, dispondrá de todo lo necesario para funcionar porque:

Antes de la ejecución de los tests, TestContainers mediante los eventos de JUnit habrá levantado el DockerComposeContainer.
Después, JUnit procesará el @BeforeAll, donde hemos seteado las propiedades necesarias para el contexto de Spring, como message-store-db.port, con el valor que dispondrá cada servicio ya esperando conexiones.

Y el post terminaría aquí, si no fuera porque:
¿Funcionaría este approach si AbstractIntegrationTest fuera extendida por más de una implementación?
Correcto, en lugar de usar el ejemplo de TestContainers lo he puesto en una abstracción, porque como deduciréis, la respuesta es NO.

Si ejecutáramos sólo 1 clase de tests extendiendo AbstractIntegrationTest, ya veríamos una cosa que nos debería chirriar en los logs:

El test pasa, y al terminar, TestContainers intercepta el final de ejecución de los tests de la clase mediante JUnit y detiene el contenedor, antes de que se cierre el contexto de Spring.

¿Por qué y por qué puede ser un problema?

Eso pasa porque Spring, va a mantener el mismo ApplicationContext para la ejecución de todos los tests de todas las clases que no estén marcadas con @DirtiesContext, para evitar el coste de levantar el contexto para cada clase anotada con @SpringBootTest.

Y eso puede ser un problema si nos interesa hacer grupos de tests (por ejemplo, una clase de test para cada @RestController si estamos desarrollando APIs), ya que

los servicios dockerizados, al volverse a levantar, van a tener otro puerto libre designado para conectarnos a ellos.
aunque se ejecute el @BeforeAll asignando nuevos puertos a System, el contexto de Spring no los va a usar dado que no se va a refrescar.

Y como seguramente no nos va a interesar que los servicios dockerizados se apaguen y levanten de nuevo para cada conjunto de tests, por el coste en tiempo, esto nos lleva a la gestión manual de los contenedores, ya que There is no special support for this use case provided by the Testcontainers extension tal como indica la sección Singleton containers de la documentación.

Pero no preocuparse, trabajamos con Spring por lo que los singletons no nos dan miedo, ¿no? ;)

TestContainers Singleton gestionados manualmente, con ciclo de vida controlado por JUnit

código de referencia de este punto

JUnit5 tiene una característica que nos permite anidar en una única clase, mediante @Nested, conjuntos de clases (test cases) que a su vez definen los tests a ejecutar.

Así que podemos:

Tener una clase única, anotada con @SpringBootTest para levantar el contexto de Spring, en la que el ciclo de de vida de JUnit (@BeforeAll -> ejecución de los tests de cada test case -> @AfterAll) va a ser el mismo que el de Spring.
Definir test cases independientes con su grupo de @Test a ejecutar.
Anidar a la clase única estos test cases con @Nested

Algo tal que así:

public class IntegrationTest {

  private static final DockerizedInfrastructure DOCKERIZED_INFRASTRUCTURE = new DockerizedInfrastructure();

  @BeforeAll
  static void dockerComposeUp() {
    DOCKERIZED_INFRASTRUCTURE.start();
  }

  @AfterAll
  static void dockerComposeDown() {
    DOCKERIZED_INFRASTRUCTURE.stop();
  }

  @Nested
  class Application extends ApplicationTestCase {
  }
}

Sólo necesitaremos que en este caso, ApplicationTest de la rama master, sea abstracta (y para este ejemplo, renombrada a ApplicationTestCase que define mejor su intención).

A parte, para hacer legible el ejemplo y evitar una mezcla de responsabilidades entre la coordinación de los tests que hará IntegrationTest y la coordinación de los servicios dockerizados, aquí sólo queda el singleton DOCKERIZED_INFRASTRUCTURE para poderlo gestionar al inicio y final de la ejecución de test cases, pero su implementación se ha separado a:

DockerizedInfrastructure.java

public class DockerizedInfrastructure {

  private static final String MESSAGE_STORE_DB_SERVICE = "message-store-db";
  private static final Integer MESSAGE_STORE_DB_PORT = 5432;
  private static final String SPRING_MESSAGE_STORE_DB_PORT = "message-store-db.port";

  private static final String MQ_SERVER_SERVICE = "mq-server";
  private static final Integer MQ_SERVER_PORT = 5672;
  private static final String SPRING_MQ_SERVER_PORT = "mq-server.port";

  private final DockerComposeContainer dockerServices;

  public DockerizedInfrastructure() {
    // Inicializamos los servicios de docker-compose
    dockerServices = new DockerComposeContainer<>(new File("docker-compose.yml"))
          .withLocalCompose(true)
          .withExposedService(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)
          .withExposedService(MQ_SERVER_SERVICE, MQ_SERVER_PORT);
  }

  public void start() {
    // Arrancamos los servicios dockerizados
    dockerServices.start();

    // Seteamos System properties para propiedades del contexto de Spring
    setProperty(SPRING_MESSAGE_STORE_DB_PORT, valueOf(dockerServices.getServicePort(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)));
    setProperty(SPRING_MQ_SERVER_PORT, valueOf(dockerServices.getServicePort(MQ_SERVER_SERVICE, MQ_SERVER_PORT)));
  }

  public void stop() {
    // Apagamos los servicios dockerizados
    dockerServices.stop();
  }
}

Y llegados a este punto, que ahora sí funcionará tal como esperamos a medida que el proyecto vaya creciendo y necesitemos agrupar los tests en distintos test cases, otra vez daría el post por cerrado, si no fuera que ¿realmente es necesario que gestionemos manualmente un singleton y su ciclo de vida con JUnit para coordinarlo con el ciclo de vida del ApplicationContext de Spring?

Y aunque no suponga un problema hacerlo, otra vez la respuesta es NO, dado que Spring, como ya comenté, va a mantener el ApplicationContext durante la ejecución de los tests y dispone de una serie de características que nos permitirán jugar con la gestión de los servicios dockerizados, las propiedades para el ApplicationContext (en este caso los puertos de los servicios),...

Además, con esta gestión manual, nos podríamos encontrar con los siguientes inconvenientes:

Añadir un nuevo test case requiere modificación en la base IntegrationTest.
Ya sea por reagrupación de test cases o para configuraciones distintas por grupos de test cases, no podríamos tener 2 IntegrationTest distintos anidando distintos test cases, sin más. Por ejemplo:

Supongamos que replicamos el ApplicationTestCase varias veces y los anidamos en también una réplica de IntegrationTest:

Al ser réplicas, en los IntegrationTestN, @BeforeAll y @AfterAll reinician los contenedores pero de nuevo, nos encontramos que el ApplicationContext para los ApplicationTestCaseN... es el mismo y por tanto, sólo iniciará la conexión a las infraestructuras la primera vez que además, JUnit no va a ejecutar en un mismo orden, por lo que el segundo bloque de tests ejecutado va a fallar:

Para resolver este problema, tendríamos que limpiar el contexto de Spring para cada ApplicationTestN, de manera que cada test case creara un nuevo ApplicationContext con configuración fresca de los puertos activados, marcándolos todos ellos con dirties context:

@SpringBootTest
@DirtiesContext

Esto de nuevo, aunque lógicamente es un corner case forzado para validar posibles flaquezas de la solución, nos lleva a pensar que realmente, lo ideal sería que la gestión del ciclo de vida de los servicios dockerizados fueran gestionados directamente con Spring.

Así, que como guindilla del pastel, continuamos :)

TestContainers sólo gestionados por Spring

código de referencia de este punto

Llegados a este punto, sabemos que:

Los test de integración marcados con @SpringBootTest comparten el ApplicationContext a no ser que sean marcados con @DirtiesContext
DockerizedInfrastructure debería ser tratado como un singleton (@Component) dentro del contexto de Spring para que en todo momento, el ApplicationContext pueda accederlo o regenerarlo en dirties.
DockerizedInfrastructure debe reconfigurar las propiedades de conexión de la infraestructura.

⚠️ pero, si hacemos un @Component, que Spring inicializa, ya no podemos setear las propiedades en System, dado que la lectura de beans (y propiedades) es anterior a la instanciación.

💡 pero por otro lado es Spring, y siempre tiene una solución a cómo gestionar estos casos: podemos usar el ConfigurableApplicationContext para refrescar el contexto con las propiedades iniciales tal como nos va a interesar.

En definitiva, para que sea gestionado completamente por Spring, podríamos modificar DockerizedInfrastructure.java así:

@Component
public class DockerizedInfrastructure {

  private static final String MESSAGE_STORE_DB_SERVICE = "message-store-db";
  private static final Integer MESSAGE_STORE_DB_PORT = 5432;
  private static final String SPRING_MESSAGE_STORE_DB_PORT = "message-store-db.port";

  private static final String MQ_SERVER_SERVICE = "mq-server";
  private static final Integer MQ_SERVER_PORT = 5672;
  private static final String SPRING_MQ_SERVER_PORT = "mq-server.port";

  private final DockerComposeContainer dockerServices;

  DockerizedInfrastructure(ConfigurableApplicationContext configurableApplicationContext) {
    // Inicializamos los servicios de docker-compose
    dockerServices = new DockerComposeContainer<>(new File("docker-compose.yml"))
          .withLocalCompose(true)
          .withExposedService(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)
          .withExposedService(MQ_SERVER_SERVICE, MQ_SERVER_PORT);

    // Arrancamos los servicios dockerizados
    dockerServices.start();

    // Refrescamos el contexto de Spring con los puertos designados
    TestPropertyValues.of(
          format("%s=%s",
                SPRING_MESSAGE_STORE_DB_PORT,
                dockerServices.getServicePort(MESSAGE_STORE_DB_SERVICE, MESSAGE_STORE_DB_PORT)),
          format("%s=%s",
                SPRING_MQ_SERVER_PORT,
                dockerServices.getServicePort(MQ_SERVER_SERVICE, MQ_SERVER_PORT))
    ).applyTo(configurableApplicationContext.getEnvironment());
  }

  @PreDestroy
  void preDestroy() {
    // Apagamos los servicios dockerizados
    dockerServices.stop();
  }
}

Fijaros que aquí, DockerizedInfrastructure no tiene ni el constructor ni ningún método público, dado que ahora no es necesario que ninguna clase de test acceda a ella para manipular su estado. Sí lo es la declaración de la clase, luego veremos por qué :)

Con el @PreDestroy nos aseguramos de apagar los servicios dockerizados cuando el ApplicationContext emita la señal de que está siendo destruido, que será o cuando hayan terminado los tests, o cuando un test esté marcado con @DirtiesContext, antes de la recreación del contexto.

Ésta sería una manera muy elegante de integrar esta DockerizedInfrastructure dado que no haría falta modificar nada en nuestra configuración de los tests, pero ¿qué pasaría si algún componente del servicio necesitara acceder a la base de datos durante la creación del contexto de Spring?

Para forzar el caso, os pongo este ejemplo:

@Component
public class InventBreaker {

  private final MessageMapper messageMapper;

  public InventBreaker(MessageMapper messageMapper) {
    this.messageMapper = messageMapper;
  }

  @PostConstruct
  void tryToBreakTheTestContext() {
    messageMapper.selectOneByText("applicationContext lanzará excepción si no hay conectividad a la BBDD");
  }
}

Supongamos que InventBreaker, por lo que sea, necesita inicializarse con un valor de la BBDD, y si no hacemos nada, va a pasar esto:

Spring, la única instrucción a la que va a hacer caso para que InventBreaker se espere a que DockerizedInfrastructure haya hecho la magia es con @DependsOn("dockerizedInfrastructure"), pero wait! Si InventBreaker forma parte del código del servicio en lugar del código de test, no podemos hacer esto.

💡 pero de nuevo, Spring ya contempla casi todos los corner cases que nos podamos imaginar, y nos va a permitir sincronizar la creación del contexto requerido para test con el contexto requerido para la aplicación modificando sólo una línea en la declaración de @SpringBootTest, dejando nuestra abstracción de tests de integración así:

@SpringBootTest(classes = {DockerizedInfrastructure.class, Application.class})

Y listo! Ahora todo se inicializará y se apagará según el orden esperado.

Además, podríamos abstraer esta definición para ser usada en cualquier otra clase de test así:

AbstractIntegrationTest.java

@SpringBootTest(classes = {DockerizedInfrastructure.class, Application.class})
abstract class AbstractIntegrationTest {
}

Y todas las clases de test con un extends AbstractIntegrationTest dispondrán de los servicios dockerizados para operar con ellos, sin necesidad de que ninguno esté marcado con @DirtiesContext, aunque marcándolo también funcionaría (pagando el coste de reiniciar el contexto, junto con los servicios dockerizados).

🚀

Conclusión

TestContainers es una herramienta muy potente para evitar que perdamos tiempo simulando / mockeando lo que debería hacer nuestra capa de integración con infraestructura a la hora de desarrollar los tests y es bueno aprovecharse de ello!

Aún así, no siempre hay una manera de implementar las cosas y es mejor adaptarse a la que mejor nos convenga en cada caso con conocimiento de las herramientas que estamos usando, y cuando usamos un framework como Spring, éste dispone para nosotros muchas facilidades para agilizar los desarrollos, tanto de la aplicación, como en este caso de los tests.

Y llegados a este punto, no queda mucho más que decir por mi parte, espero que os haya gustado este viaje a las entrañas de Spring en el contexto de testing, así que si es el caso o si gestionáis el ciclo de vida de los contenedores de test de alguna otra forma y queréis compartirla dejad un comentario, que me gustará leeros.

Y ahora sí, fin :)