back java tests

Maîtrisez les Tests de Charge avec Gatling pour Spring Boot

Publié le 18/06/2025 Source : sfeir.dev

Dans le développement d’applications web, la performance est un facteur clé pour garantir une expérience utilisateur optimale. Les applications développées avec Spring Boot, framework populaire pour sa simplicité et sa robustesse, doivent souvent supporter un volume important de requêtes simultanées. Les tests de performance permettent de simuler ces conditions pour évaluer la capacité de l’application à répondre efficacement en termes de temps de réponse et de fiabilité.

Pour cela, Gatling se positionne comme un outil open-source puissant et adapté aux tests de charge et de performance. Dans cet article, nous allons explorer comment utiliser Gatling pour tester une API Spring Boot, en nous appuyant sur un exemple concret de simulation de création d’auteurs via une requête POST. Cet exemple servira de base pour illustrer chaque étape du processus.

Présentation de Gatling

Gatling est un outil de test de performance conçu pour simuler des charges importantes sur des applications web. Écrit en Scala, il est néanmoins parfaitement utilisable dans des projets Java, ce qui le rend idéal pour les développeurs travaillant avec Spring Boot.
Gatling excelle dans la création de scénarios de charge réalistes, en envoyant des requêtes simultanées à une application et en analysant ses performances via des rapports détaillés.

Ses principales caractéristiques incluent :

Gatling est largement reconnu dans la communauté pour sa capacité à simuler des montées en charge progressives et à fournir des données précises sur les performances, ce qui en fait un choix privilégié pour tester les applications Spring Boot.

](https://github.com/gatling/gatling?ref=sfeir.dev)

⚖️ Avantages et inconvénients de Gatling

➕ Avantages

➖ Inconvénients

Mise en place

Pour intégrer Gatling dans un projet Spring Boot, il faut configurer le fichier pom.xml avec les dépendances et plugins nécessaires.

<dependency>
    <groupId>io.gatling</groupId>
    <artifactId>gatling-app</artifactId>
    <version>3.13.5</version>
</dependency>
<dependency>
    <groupId>io.gatling.highcharts</groupId>
    <artifactId>gatling-charts-highcharts</artifactId>
    <version>3.13.5</version>
</dependency>
<dependency>
    <groupId>io.gatling</groupId>
    <artifactId>gatling-maven-plugin</artifactId>
    <version>4.16.3</version>
</dependency>

Les dépendances Gatling

Dépendances Gatling :

Petit plus

Légionnaire romain Petiplus (image générée par IA)

Vous pouvez également ajouter les dépendances suivantes :

<dependency>
    <groupId>com.github.javafaker</groupId>
    <artifactId>javafaker</artifactId>
    <version>1.0.2</version>
</dependency>
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <scope>provided</scope>
</dependency>

Les dépendances utiles

Avec cette configuration, le projet est prêt à exécuter des tests de performance avec Gatling.

Exemple de simulation

Nous allons définir une classe AuthorSimulation qui va illustrer une simulation Gatling testant la création d’auteurs via une requête POST sur l’endpoint /authors d’une API Spring Boot.
Examinons chaque méthode en détail.

Configuration du protocole HTTP

La méthode setupProtocolForSimulation définit les paramètres globaux des requêtes HTTP :

private static HttpProtocolBuilder setupProtocolForSimulation() {
    return http.baseUrl("http://localhost:8080")
            .acceptHeader("application/json")
            .maxConnectionsPerHost(10)
            .userAgentHeader("Gatling/Performance Test");
}

Génération des données de test

La méthode setupTestFeedData utilise JavaFaker pour produire des données dynamiques :

private static Iterator<Map<String, Object>> setupTestFeedData() {
    Faker faker = new Faker();
    Iterator<Map<String, Object>> iterator;
    iterator = Stream.generate(() -> {
                Map<String, Object> stringObjectMap = new HashMap<>();
                stringObjectMap.put("name", faker.name()
                        .fullName());
                stringObjectMap.put("bio", faker.lorem().sentence(15));
                return stringObjectMap;
            })
            .iterator();
    return iterator;
}

Définition du scénario

La méthode buildPostScenario décrit le scénario de test :

private static ScenarioBuilder buildPostScenario() {
    return CoreDsl.scenario("Load Test Creating Author")
            .feed(FEED_DATA)
            .exec(session -> {
                String name = session.getString("name");
                String bio = session.getString("bio");
                String jsonBody = """
                                    {
                                        "name": "%s",
                                        "bio": "%s"
                                    }
                                    """.formatted(name, bio);
                return session.set("jsonBody", jsonBody);
            })
            .exec(http("create-author-request").post("/authors")
                    .header("Content-Type", "application/json")
                    .body(StringBody(session -> session.getString("jsonBody")))
                    .check(status().is(200)));
}

Injection d’utilisateurs

La méthode postEndpointInjectionProfile configure la montée en charge :

private RampRateOpenInjectionStep postEndpointInjectionProfile() {
    int totalDesiredUserCount = 50;
    double userRampUpPerInterval = 10;
    double rampUpIntervalSeconds = 20;
    int totalRampUptimeSeconds = 20;
    int steadyStateDurationSeconds = 60;
    return rampUsersPerSec(userRampUpPerInterval / (rampUpIntervalSeconds / 60)).to(totalDesiredUserCount)
            .during(Duration.ofSeconds(totalRampUptimeSeconds + steadyStateDurationSeconds));
}

Assertions

Les assertions, définies dans le constructeur, valident les performances :

public AuthorSimulation() {
    setUp(POST_SCENARIO_BUILDER.injectOpen(postEndpointInjectionProfile())
            .protocols(HTTP_PROTOCOL_BUILDER)).assertions(global().responseTime()
            .max()
            .lte(10000), global().successfulRequests()
            .percent()
            .gt(90d));
}

Le rapport de test généré

Une fois la simulation terminée, Gatling produit un rapport HTML contenant :

Ce rapport permet d’identifier les goulets d’étranglement, de valider les assertions et d’évaluer si l’application répond aux exigences de performance. Il est généré automatiquement dans le dossier target/gatling après l’exécution via mvn gatling:test.

Conclusion

Gatling est un outil incontournable pour tester les performances des applications Spring Boot. Avec sa DSL intuitive, son intégration Maven et ses rapports détaillés, il permet de simuler des charges réalistes et d’analyser les résultats efficacement.

En intégrant les tests de performance dans leur workflow, les développeurs peuvent s’assurer que leurs applications restent robustes et rapides, même sous forte charge.