Tests Spring Boot

Cette skill fournit un guide expert pour tester les applications Spring Boot 4 avec des patterns modernes et les meilleures pratiques.

Principes fondamentaux

1. Pyramide de test : Unitaires (rapides) > Tranche (ciblés) > Intégration (complets)
2. Bon outil : Utilisez la tranche la plus étroite qui vous donne confiance
3. Style AssertJ : Assertions fluides et lisibles plutôt que des matchers verbeux
4. APIs modernes : Préférez MockMvcTester et RestTestClient aux alternatives héritées

Quelle tranche de test ?

Référence des tranches de test

• references/test-slices-overview.md - Matrice de décision et comparaison
• references/webmvctest.md - Couche web avec MockMvc
• references/datajpatest.md - Couche données avec Testcontainers
• references/restclienttest.md - Tests de client REST

Référence des outils de test

• references/mockmvc-tester.md - MockMvc style AssertJ (3.2+)
• references/mockmvc-classic.md - MockMvc traditionnel (pré-3.2)
• references/resttestclient.md - Client REST Spring Boot 4+
• references/mockitobean.md - Mocking de dépendances

Bibliothèques d'assertions

• references/assertj-basics.md - Scalaires, chaînes, booléens, dates
• references/assertj-collections.md - Listes, Sets, Maps, tableaux

Testcontainers

• references/testcontainers-jdbc.md - PostgreSQL, MySQL, etc.

Génération de données de test

• references/instancio.md - Générer des objets de test complexes (3+ propriétés)

Performance et migration

• references/context-caching.md - Accélérer les suites de tests
• references/sb4-migration.md - Changements Spring Boot 4.0

Arbre de décision rapide

Tester un endpoint de contrôleur ?
  Oui → @WebMvcTest avec MockMvcTester

Tester des requêtes repository ?
  Oui → @DataJpaTest avec Testcontainers (vraie BD)

Tester la logique métier dans un service ?
  Oui → JUnit simple + Mockito (pas de contexte Spring)

Tester un client API externe ?
  Oui → @RestClientTest avec MockRestServiceServer

Tester le mapping JSON ?
  Oui → @JsonTest

Besoin d'un test d'intégration complet ?
  Oui → @SpringBootTest avec config minimale du contexte

Actualités Spring Boot 4

• RestTestClient : Alternative moderne à TestRestTemplate
• @MockitoBean : Remplace @MockBean (déprécié)
• MockMvcTester : Assertions style AssertJ pour les tests web
• Starters modulaires : Starters de test spécifiques aux technologies
• Context pausing : Pause automatique des contextes en cache (Spring Framework 7)

Meilleures pratiques de test

Évaluation de la complexité du code

Quand une méthode ou une classe est trop complexe pour être testée efficacement :

1. Analyser la complexité - Si vous avez besoin de plus de 5-7 cas de test pour couvrir une seule méthode, c'est probablement trop complexe
2. Recommander une refactorisation - Suggérez de casser le code en fonctions plus petites et ciblées
3. Décision de l'utilisateur - Si l'utilisateur accepte de refactoriser, aidez à identifier les points d'extraction
4. Procéder si nécessaire - Si l'utilisateur décide de continuer avec le code complexe, implémentez les tests malgré la difficulté

Exemple de recommandation de refactorisation :

// Avant : Méthode complexe difficile à tester
public Order processOrder(OrderRequest request) {
  // Validation, calcul de remise, paiement, inventaire, notification...
  // 50+ lignes de responsabilités mélangées
}

// Après : Refactorisé en unités testables
public Order processOrder(OrderRequest request) {
  validateOrder(request);
  var order = createOrder(request);
  applyDiscount(order);
  processPayment(order);
  updateInventory(order);
  sendNotification(order);
  return order;
}

Éviter la redondance de code

Créez des méthodes d'aide pour les objets et le setup de mock couramment utilisés afin d'améliorer la lisibilité et la maintenabilité.

Organisation des tests avec @DisplayName

Utilisez des noms d'affichage descriptifs pour clarifier l'intention du test :

@Test
@DisplayName("Should calculate discount for VIP customer")
void shouldCalculateDiscountForVip() { }

@Test
@DisplayName("Should reject order when customer has insufficient credit")
void shouldRejectOrderForInsufficientCredit() { }

Ordre de couverture de test

Structurez toujours les tests dans cet ordre :

1. Scénario principal - Le chemin heureux, le cas d'usage le plus courant
2. Autres chemins - Scénarios valides alternatifs, cas limites
3. Exceptions/Erreurs - Entrées invalides, conditions d'erreur, modes de défaillance

Tester les scénarios de production

Écrivez des tests en gardant à l'esprit les scénarios réels de production. Cela rend les tests plus pertinents et aide à comprendre le comportement du code dans les cas réels.

Objectifs de couverture de test

Viser 80 % de couverture de code comme équilibre pratique entre qualité et effort. Une couverture plus élevée est bénéfique mais pas le seul objectif.

Utilisez le plugin maven Jacoco pour le rapport et le suivi de couverture.

Règles de couverture :

• 80+ % de couverture minimum
• Concentrez-vous sur les assertions significatives, pas seulement l'exécution

À prioriser :

1. Chemins critiques pour l'entreprise (traitement des paiements, validation des commandes)
2. Algorithmes complexes (tarification, calculs de remise)
3. Gestion des erreurs (exceptions, cas limites)
4. Points d'intégration (APIs externes, bases de données)

Dépendances (Spring Boot 4)

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
</dependency>

<!-- Pour les tests WebMvc -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webmvc-test</artifactId>
  <scope>test</scope>
</dependency>

<!-- Pour Testcontainers -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-testcontainers</artifactId>
  <scope>test</scope>
</dependency>