Parité développement/production : Spring Boot Testcontainers

Introduction

La parité Dev/Prod vise à réduire l'écart entre les environnements de développement et de production. Cet article cible le manque d'outils, en particulier dans les tests d'intégration avec Spring Testcontainers, afin de rendre le développement et la production aussi similaires que possible.
Lorsque nous effectuons des tests d'intégration impliquant des bases de données, nous devons gérer toutes les opérations CRUD avec soin. Ceci est crucial dans un environnement de base de données centralisé où un test, tel que TestDeleteUserByID_ShouldReturnOk(), pourrait « accidentellement » décider d’effacer le compte de notre client le plus fidèle qui est avec nous depuis 2015 ?‍♂️
Pour atténuer ces risques, nous pouvons envisager des solutions telles que les transactions de base de données pour isoler les données de test. Par exemple, un test pourrait démarrer une transaction pour modifier des données, puis revenir en arrière à la fin, laissant ainsi la base de données dans son état d'origine.
Cependant, cela soulève un problème critique : QU'EST-CE QUI TEST LE TEST ?

Que se passe-t-il si l'isolation échoue et que le code exécute des modifications qui ne sont pas annulées d'une manière ou d'une autre, entraînant des fuites de données dans l'environnement de production ? Les dégâts potentiels dans de tels scénarios sont importants.

Alternativement, les tests autonomes avec une base de données en mémoire comme H2DB présentent également certains défis. même s'il est facile à configurer, H2DB diffère du SGBDR, il y a donc une forte probabilité que les tests donnent des résultats différents entre les environnements de développement et de production, nous ne pouvons donc pas faire confiance à ces résultats.

https://stackoverflow.com/questions/62778900/syntax-error-h2-database-in-postgresql-compatibility

La solution suivante, la moins problématique, consiste à cloner la base de données, offrant une approche moins risquée avec un environnement de production. Cependant, cette méthode a ses limites. Étant donné que les ORM automatisent la création et la configuration du schéma de la base de données de production, nous devons réfléchir à la manière de synchroniser la base de données de développement clonée.

Testez tout ce que vous pouvez conteneuriser : base de données, courtier de messages, etc.

"Testcontainers est une bibliothèque Java qui prend en charge les tests JUnit, fournissant des instances légères et jetables de bases de données courantes, de navigateurs Web Selenium ou de tout autre élément pouvant s'exécuter dans un conteneur Docker."

Développé à l'origine pour Java, il a depuis été étendu pour prendre en charge d'autres langages comme Go, Rust et .NET.

L'idée principale de Testcontainers est de fournir une infrastructure à la demande, exécutable à partir de l'EDI, où les tests peuvent être effectués sans avoir besoin de se moquer ou d'utiliser des services en mémoire, et avec un nettoyage automatique.

Nous pouvons y parvenir en trois étapes :

• Démarrez les services requis et préparez l'infrastructure en configurant des conteneurs Docker et configurez votre application pour utiliser cette configuration comme infrastructure de test.
• Exécutez vos tests sur l'infrastructure dockerisée.
• Nettoyer automatiquement l'infrastructure dockerisée une fois les tests terminés

Documentation de la bibliothèque Testcontainers

Implémentation des conteneurs de test Spring Boot

Dans ApplicationIntegrationTests, qui est la classe de base pour les tests d'intégration, nous définissons un PostgreSQLContainer statique. Ce conteneur est utilisé dans toutes les instances de test dérivées de cette classe.

L'annotation @Testcontainers permet la découverte de tous les champs annotés avec @Container, la gestion de leurs méthodes de cycle de vie des conteneurs et le démarrage des conteneurs.

• Les conteneurs déclarés comme champs statiques sont partagés entre les méthodes de test. Ils ne sont démarrés qu'une seule fois avant l'exécution d'une méthode de test et arrêtés après l'exécution de la dernière méthode de test.
• Les conteneurs déclarés comme champs d'instance sont démarrés et arrêtés pour chaque méthode de test.

L'annotation @DynamicPropertySource nous permet d'injecter dynamiquement des propriétés dans notre environnement de test.

@Testcontainers
@ActiveProfiles("test")
public abstract class ApplicationIntegrationTests {
    @Container
    protected static PostgreSQLContainer<?> postgres=new PostgreSQLContainer<>("postgres:17.2-alpine")
            .withDatabaseName("testcontainersproject")
            .withUsername("root")
            .withPassword("root");

    @DynamicPropertySource
    static void initialize(DynamicPropertyRegistry registry)
    {
        registry.add("spring.datasource.url",postgres::getJdbcUrl);
        registry.add("spring.datasource.username",postgres::getUsername);
        registry.add("spring.datasource.password",postgres::getPassword);
    }


}

Alternativement, nous pouvons ignorer l'utilisation de @Testcontainers et @Container et gérer le cycle de vie du conteneur directement à l'aide de @BeforeAll et @AfterAll. Cette approche permet plus de contrôle sur le moment et la manière dont les conteneurs sont démarrés et arrêtés

@BeforeAll
public static void runContainer(){
        postgres.start();
}
@AfterAll
static void stopContainers() {
    postgres.stop();
}

Dans la méthode de rappel @AfterAll, nous arrêtons explicitement le conteneur Postgres. Cependant, même si nous n'arrêtons pas explicitement le conteneur, Testcontainers nettoiera et arrêtera automatiquement les conteneurs à la fin du test.

Nous pouvons désormais créer des tests d'intégration en étendant ApplicationIntegrationTests comme suit.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class CategoryControllerTest extends ApplicationIntegrationTests {
    private static final String CATEGORY_ENDPOINT="/categories";
   @Autowired
    private MockMvc mockMvc;
    @Autowired
    private CategoryRepository categoryRepository;

    @Test
    void TestGetAllCategories_ShouldReturnOk() throws Exception {

        List<Category> categories = List.of(
                new Category("Electronics", "All kinds of electronic gadgets from smartphones to laptops"),
                new Category("Books", "A wide range of books from novels to educational textbooks")
        );
        categoryRepository.saveAll(categories);
        MvcResult mvcResult=mockMvc.perform(
                get(CATEGORY_ENDPOINT).
                        contentType(MediaType.APPLICATION_JSON)
        )
                .andExpect(status().isOk())
                .andReturn();
        var response=mvcResult.getResponse().getContentAsString();
        assertNotNull(response);
        assertFalse(response.isEmpty());
    }
}

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!