Stratégies de Test

Comprendre quand utiliser chaque type de test et comment construire une suite de tests efficace pour l’architecture hexagonale.

La pyramide de tests guide vos décisions : beaucoup de tests unitaires rapides, quelques tests d’intégration, et peu de tests E2E.

La Pyramide de Tests

📊 Pyramide

La Pyramide Classique


           /\
          /  \         E2E Tests (5%)
         /----\        - Lents (secondes/minutes)
        / Inte \       - Fragiles
       /  gration\     - Coûteux à maintenir
      /------------\
     /              \  Integration Tests (15%)
    /  Unit Tests   \ - Moyennement rapides
   /------------------\- Tests avec dépendances
  /____________________\
                        Unit Tests (80%)
                        - Ultra rapides (ms)
                        - Stables
                        - Faciles à maintenir

Principe de base : Plus on monte dans la pyramide, plus les tests sont :

❌ Lents à exécuter
❌ Fragiles (cassent facilement)
❌ Coûteux à maintenir
✅ Réalistes (proches de la prod)

Type	Vitesse	Isolation	Couverture	Maintenance	Proportion
Unit	⚡⚡⚡ Ultra rapide (ms)	✅ Totale	🎯 Une classe	✅ Facile	80%
Integration	⚡⚡ Rapide (100ms)	⚠️ Partielle	🔗 Plusieurs couches	⚠️ Moyenne	15%
E2E	⚡ Lent (secondes)	❌ Aucune	🌐 Système complet	❌ Difficile	5%
Architecture	⚡⚡⚡ Ultra rapide	✅ Totale	🏗️ Structure code	✅ Facile	Bonus

🎯 Quand Utiliser

Quand Utiliser Chaque Type ?

Tests Unitaires (80%) ✅

Utilisez pour :

✅ Logique métier pure (domain)
✅ Use cases (application)
✅ Validation de règles
✅ Calculs, transformations
✅ Gestion d’erreurs

Exemple :


// Tester la logique métier
@Test
void shouldRejectInvalidKeyword() {
    // Given
    var request = new TrendRequest("@#$%", "US");
 
    // When/Then
    assertThrows(InvalidKeywordException.class,
        () -> useCase.execute(request));
}

Tests d’Intégration (15%) ⚠️

Utilisez pour :

⚠️ Interaction avec base de données
⚠️ Appels HTTP réels
⚠️ Injection de dépendances Micronaut
⚠️ Configuration complète
⚠️ Serialisation JSON

Exemple :


@MicronautTest
class TrendControllerIntegrationTest {
    @Test
    void shouldReturnTrendsFromAPI() {
        // Teste tout le flux HTTP → Use Case → Adapter → API
    }
}

Tests E2E (5%) ❌

Utilisez pour :

❌ Scénarios critiques uniquement
❌ Parcours utilisateur complets
❌ Tests de smoke en prod

Note : Non couverts dans cette formation (hors scope architecture hexagonale)

Tests d’Architecture (Bonus) 🏗️

Utilisez toujours :

✅ Garantir respect de l’architecture
✅ Détecter violations automatiquement
✅ Documentation vivante

Stratégies par Couche

Domain

Tests du Domain Layer

Le domain est 100% testable en unitaire car il n’a AUCUNE dépendance externe.

Que Tester ?

Valider les règles métier


@Test
void trendResultShouldRejectNegativeValues() {
    assertThrows(IllegalArgumentException.class,
        () -> new TrendResult("java", -10, "2025-01-15"));
}

Tester les Value Objects


@Test
void keywordShouldNormalizeInput() {
    var keyword = new Keyword("  JAVA  ");
    assertEquals("java", keyword.value());
}

Vérifier l’immutabilité


@Test
void trendResultShouldBeImmutable() {
    var result = new TrendResult("java", 85, "2025-01-15");
    // Impossible de modifier les valeurs
}

Stratégie Recommandée

✅ 100% de couverture sur le domain
✅ Tests unitaires purs (pas de mocks)
✅ AAA pattern (Arrange/Act/Assert)
✅ Tests rapides (ms)

Application

Tests de l’Application Layer

L’application layer orchestre le domain et les ports. Utilisez des mocks pour les ports.

Que Tester ?

Mocker les ports (Output)


@BeforeEach
void setUp() {
    mockRepository = mock(TrendRepository.class);
    useCase = new GetTrendsUseCase(mockRepository);
}

Tester l’orchestration


@Test
void shouldCallRepositoryWithCorrectParams() {
    // Given
    var request = new TrendRequest("java", "US");
 
    // When
    useCase.execute(request);
 
    // Then
    verify(mockRepository).getTrends("java", "US");
}

Vérifier la gestion d’erreurs


@Test
void shouldThrowWhenRepositoryFails() {
    // Given
    when(mockRepository.getTrends(any(), any()))
        .thenThrow(new RepositoryException());
 
    // When/Then
    assertThrows(UseCaseException.class,
        () -> useCase.execute(request));
}

Stratégie Recommandée

✅ Tests unitaires avec Mockito
✅ Mocker tous les ports
✅ Tester l’orchestration, pas l’implémentation
✅ Vérifier les appels (verify)

Infrastructure

Tests de l’Infrastructure Layer

L’infrastructure nécessite des tests d’intégration car elle interagit avec des systèmes externes.

Que Tester ?

Adapters avec dépendances réelles


@MicronautTest
class TrendRepositoryAdapterTest {
 
    @Inject
    TrendRepositoryAdapter adapter;
 
    @Test
    void shouldFetchRealDataFromAPI() {
        var results = adapter.getTrends("java", "US");
        assertNotNull(results);
    }
}

Configuration Micronaut


@Test
void contextLoads() {
    // Vérifie que tous les beans démarrent
}

Serialisation JSON


@Test
void shouldMapJsonToDto() {
    var json = """
        {
          "keyword": "java",
          "value": 85
        }
        """;
    var dto = objectMapper.readValue(json, TrendDto.class);
    assertEquals("java", dto.getKeyword());
}

Stratégie Recommandée

⚠️ Tests d’intégration avec @MicronautTest
⚠️ Mocker les appels externes si coûteux
⚠️ Tester la configuration réelle
⚠️ Vérifier la conversion DTO ↔ Domain

Stratégie Complète pour un Use Case

Voici comment tester un use case complet en suivant la pyramide.

Exemple : GetTrendsUseCase

Tests Unitaires du Domain (80%)


// Tester TrendResult, TrendRequest, règles métier
class TrendResultTest {
    @Test void shouldCreateValidTrendResult() { }
    @Test void shouldRejectNegativeValue() { }
    @Test void shouldFormatDateCorrectly() { }
}

Objectif : Valider TOUTE la logique métier.

Tests Unitaires de l’Application (80%)


// Tester GetTrendsUseCase avec mocks
class GetTrendsUseCaseTest {
    @Mock TrendRepository mockRepository;
 
    @Test void shouldReturnTrends() { }
    @Test void shouldHandleErrors() { }
    @Test void shouldValidateInput() { }
}

Objectif : Tester l’orchestration sans dépendances.

Tests d’Intégration (15%)


// Tester le flux complet HTTP → Domain
@MicronautTest
class TrendControllerIntegrationTest {
    @Inject HttpClient client;
 
    @Test void shouldReturnTrendsViaHTTP() {
        var response = client.toBlocking()
            .exchange("/api/trends?keyword=java", TrendDto[].class);
        assertEquals(HttpStatus.OK, response.status());
    }
}

Objectif : Valider l’intégration complète.

Tests d’Architecture (Bonus)


// Vérifier que l'architecture est respectée
@Test
void domainShouldNotDependOnInfrastructure() {
    noClasses().that().resideInPackage("..domain..")
        .should().dependOnClassesThat()
        .resideInPackage("..infrastructure..")
        .check(classes);
}

Objectif : Garantir le respect de l’architecture.

Matrice de Décision

Utilisez ce tableau pour décider quel type de test écrire.

Vous Voulez Tester	Type de Test	Outil	Temps
Règle métier pure	✅ Unitaire	JUnit	1ms
Validation domain	✅ Unitaire	JUnit	1ms
Use case (orchestration)	✅ Unitaire	Mockito	5ms
Controller → Use Case	⚠️ Intégration	`@MicronautTest`	100ms
Appel HTTP externe	⚠️ Intégration	`@MicronautTest`	200ms
Conversion JSON ↔ DTO	⚠️ Intégration	ObjectMapper	50ms
Architecture respectée	✅ Architecture	ArchUnit	10ms
Parcours utilisateur	❌ E2E	Selenium	10s

Anti-Patterns à Éviter

❌ Trop de Mocks

Anti-Pattern : Trop de Mocks

Problème : Mocker dans les tests unitaires du domain.


// ❌ MAUVAIS : Le domain n'a pas de dépendances !
class TrendResultTest {
    @Mock SomeService mockService; // ❌ Pourquoi ?
 
    @Test
    void test() {
        // Le domain est pur, pas besoin de mocks
    }
}

Solution :


// ✅ BON : Tests purs sans mocks
class TrendResultTest {
    @Test
    void shouldCreateTrendResult() {
        var result = new TrendResult("java", 85, "2025-01-15");
        assertEquals("java", result.keyword());
    }
}

Règle : Si vous mockez dans le domain, c’est que votre domain a des dépendances → architecture incorrecte !

❌ Tests Fragiles

Anti-Pattern : Tests Fragiles

Problème : Tester l’implémentation au lieu du comportement.


// ❌ MAUVAIS : Teste l'implémentation interne
@Test
void shouldCallPrivateMethod() {
    // Utilisation de reflection pour tester des méthodes privées
    Method method = useCase.getClass().getDeclaredMethod("privateMethod");
    method.setAccessible(true);
    // ...
}

Solution :


// ✅ BON : Teste le comportement public
@Test
void shouldReturnTrendsWhenCalled() {
    var request = new TrendRequest("java", "US");
    var result = useCase.execute(request);
    assertNotNull(result);
}

Règle : Ne testez jamais les méthodes privées. Testez le comportement public.

❌ Mauvaise Couverture

Anti-Pattern : Mauvaise Couverture

Problème : Viser 100% de couverture partout.


// ❌ MAUVAIS : Tester les getters/setters
@Test
void testGetKeyword() {
    dto.setKeyword("java");
    assertEquals("java", dto.getKeyword());
}

Solution :


// ✅ BON : Tester la logique métier importante
@Test
void shouldRejectInvalidKeywordFormat() {
    var request = new TrendRequest("@@@", "US");
    assertThrows(ValidationException.class,
        () -> useCase.execute(request));
}

Règle : Visez 100% de couverture sur le domain, 80%+ sur application, et testez les cas critiques en intégration.

Checklist : Quelle Stratégie pour Votre Projet ?

Commencez par les tests d’architecture


# Installation ArchUnit
mvn archunit:check

Pourquoi en premier ? Garantit que l’architecture est respectée dès le début.

Écrivez les tests unitaires du domain

✅ Testez toutes les règles métier
✅ Validez les Value Objects
✅ Vérifiez les invariants

Objectif : 100% de couverture du domain.

Ajoutez les tests unitaires des use cases

✅ Mocker les ports (repositories, services)
✅ Tester l’orchestration
✅ Vérifier la gestion d’erreurs

Objectif : 80%+ de couverture de l’application layer.

Complétez avec des tests d’intégration

⚠️ Tester les adapters (API, BDD)
⚠️ Valider le flux HTTP complet
⚠️ Vérifier la serialisation JSON

Objectif : Cas critiques uniquement (15% du total).

Automatisez dans la CI/CD


# GitHub Actions
- name: Run tests
  run: mvn test

Objectif : Tests exécutés à chaque commit.

Récapitulatif

Une bonne stratégie de test = 80% unitaires, 15% intégration, 5% E2E + tests d’architecture.

Règles d’Or

Domain → 100% tests unitaires purs
Application → Tests unitaires avec mocks
Infrastructure → Tests d’intégration ciblés
Architecture → ArchUnit pour validation automatique

Temps d’Exécution Cible

✅ Tests unitaires : < 1 seconde pour toute la suite
⚠️ Tests d’intégration : < 30 secondes
✅ Tests d’architecture : < 1 seconde
🎯 Total : < 1 minute pour 200+ tests

Prochaines Étapes

Vous avez maintenant une stratégie complète. Passez à la pratique !

📖 Tests Unitaires - Écrire des tests unitaires avec Mockito
📖 Tests d’Intégration - Tester avec @MicronautTest
📖 Tests d’Architecture - Garantir l’architecture avec ArchUnit
📖 Tests Manuels - Valider l’API avec Postman/cURL

Stratégies de Test

La Pyramide de Tests

📊 Pyramide

⚡ Caractéristiques

🎯 Quand Utiliser

Tests Unitaires (80%) ✅

Tests d’Intégration (15%) ⚠️

Tests E2E (5%) ❌

Tests d’Architecture (Bonus) 🏗️

Stratégies par Couche

Domain

Que Tester ?

Stratégie Recommandée

Application

Que Tester ?

Stratégie Recommandée

Infrastructure

Que Tester ?

Stratégie Recommandée

Stratégie Complète pour un Use Case

Exemple : GetTrendsUseCase

Tests Unitaires du Domain (80%)

Tests Unitaires de l’Application (80%)

Tests d’Intégration (15%)

Tests d’Architecture (Bonus)

Matrice de Décision

Anti-Patterns à Éviter

❌ Trop de Mocks

❌ Tests Fragiles

❌ Mauvaise Couverture

Checklist : Quelle Stratégie pour Votre Projet ?

Commencez par les tests d’architecture

Écrivez les tests unitaires du domain

Ajoutez les tests unitaires des use cases

Complétez avec des tests d’intégration

Automatisez dans la CI/CD

Récapitulatif

Règles d’Or

Temps d’Exécution Cible

Prochaines Étapes