écrire du code testable en utilisant l'injection de dépendance pour permettre un couplage lache, comme le montre le remplacement des dépendances codées durs par des dépendances injectées; 2. Utilisez Junit 5 pour des tests structurés avec des fonctionnalités comme @BeforeEach, @Test et AssertThrows pour assurer des tests propres, lisibles et fiables; 3. Dépendances externes simulées avec Mockito Utilisation de Mock (), quand (). TherAtRurn (), et Verify () pour isoler le comportement et éviter la dépendance à l'égard des systèmes réels; 4. Suivez les meilleures pratiques telles que les noms de test descriptifs, le modèle AAA, éviter les tests de détail de mise en ?uvre, maintenir les tests indépendants, et non sur mobilisation et couvrant les cas de bord pour garantir des tests maintenables et efficaces; En fin de compte, la conception de testabilité améliore la qualité du code, ce qui facilite le changement, le débogage et la confiance.

La rédaction du code Java testable est une compétence essentielle pour construire des applications robustes maintenables. Avec JUnit 5 en tant que cadre de test moderne et Mockito pour les dépendances moqueuses, vous pouvez écrire des tests unitaires propres et fiables qui vérifient le comportement sans compter sur des systèmes externes. Voici comment structurer votre code et tester efficacement.

1. écrivez le code testable: injection de dépendance et couplage lache

Le fondement du code testable est l'injection de dépendance (DI) et le couplage lache . évitez les dépendances à code dur ou les appels statiques qui rendent les tests difficiles.

Mauvais exemple (difficile à tester):

 classe publique OrderService {
    EmailService privé EmailService = nouveau e-mail (); // Dépendance difficile

    Processus de vide public (ordre de l'ordre) {
        // logique
        EmailService.SendConfirmation (Order);
    }
}

Cela couple étroitement OrderService à EmailService , ce qui rend impossible de tester process() sans envoyer de courriels.

Bonne approche (testable avec DI):

 classe publique OrderService {
    EmailService final privé EmailService;

    Public OrderService (EmailService EmailService) {
        this.emailService = EmailService;
    }

    Processus de vide public (ordre de l'ordre) {
        // Logique commerciale
        EmailService.SendConfirmation (Order);
    }
}

Vous pouvez maintenant injecter un EmailService moqué lors des tests à l'aide de Mockito.

2. Utilisez Junit 5 pour des tests structurés et lisibles

JUnit 5 propose une syntaxe moderne avec une gestion de cycle de vie améliorée et des affirmations expressives.

Exemple de classe de test:

 import org.junit.jupiter.api. *;
importer statique org.mockito.mockito. *;
Importer Static org.junit.jupiter.api.Assesertions. *;

@Testinstance (Testinstance.lifecycle.per_method)
classe OrderServiceTest {

    EmailService privé EmailService;
    Commande d'ordre privé;

    @BeforeEach
    void setup () {
        EmailService = MOCK (EMAILSERVICE.CLASS);
        ORDERSERVICE = NOUVEAU ORDERSERVICE (EMAILSERVICE);
    }

    @Test
    @DisplayName ("devrait envoyer un e-mail de confirmation lors du traitement de la commande")
    VOID SHIDSENDEMELAILONPROCESS () {
        // Donné
        Order Order = New Order ("123", 100.0);

        // Quand
        OrderService.Process (Order);

        // Alors
        Vérifier (EmailService, Times (1)). SendConfirmation (Order);
    }

    @Test
    @DisplayName ("devrait lancer une exception pour l'ordre nul")
    void ommérrowExceptionFornullOrder () {
        // Quand et puis
        assertThrows (illégalArgumentException.class, () -> {
            OrderService.Process (null);
        });
    }
}

Fonctionnalités Key Junit 5 utilisées:

• @BeforeEach - s'exécute avant chaque test (état propre)
• @Test - Méthodes de test de marque
• @DisplayName - Améliore la lisibilité dans les rapports de test
• assertThrows - vérifie les exceptions attendues
• verify() - vérifie l'interaction avec les simulations

3. Dépendances simulées avec moquette

Mockito vous permet de simuler les services externes (par exemple, bases de données, API, e-mail) afin que vos tests unitaires s'exécutent rapidement et isolent le comportement.

Modèles de moquettes courantes:

• Création de simulation: mock(ClassName.class)
• Méthodes de coup: when(mock.method()).thenReturn(value)
• Vérification des interactions: verify(mock).method()

Exemple: Couper un appel de référentiel

 classe publique UserService {
    UserRepository final privé UserPository;

    Public UserService (UserRepository UserRepository) {
        this.userRepository = userRepository;
    }

    Utilisateur public FindUserById (String ID) {
        return userRepository.FindById (ID)
                .ORELSETHROW (() -> NOUVEAU USERNOTFOUNDException ("utilisateur non trouvé"));
    }
}

Tester avec Mockito:

 @Test
@DisplayName ("devrait renvoyer l'utilisateur lorsqu'il est trouvé dans le référentiel")
vide devrait-onTurnUser wHenfound () {
    // Donné
    UserRepository userRepository = mock (userRepository.class);
    User MockUser = nouvel utilisateur ("1", "Alice");
    quand (userRepository.FindById ("1")). thereRenturn (facultatif.of (mockUser));

    UserService userService = new UserService (userRepository);

    // Quand
    Résultat utilisateur = userService.FindUserById ("1");

    // Alors
    asserTequals ("Alice", result.getName ());
    Vérifier (userRepository) .FindById ("1");
}

Vous testez uniquement la logique dans UserService , pas la base de données réelle.

4. meilleures pratiques pour les tests propres et maintenables

Suivez ces directives pour maintenir vos tests efficaces:

• Utiliser des noms de test descriptifs
  Préférez- shouldThrowExceptionWhenOrderIsNull() sur testProcess() .

• Suivez le modèle AAA
  Organisez des tests en organiser , agir , affirmer des blocs pour plus de clarté.

• évitez de tester les détails de la mise en ?uvre
  Testez ce que fait la méthode, pas comment il le fait. Ne vérifiez pas les méthodes privées internes.

• Gardez les tests indépendants et rapides
  Aucun état partagé entre les tests. Utilisez à la place @BeforeEach ou en usine.

• Ne surclassez pas
  Seules les dépendances externes. Ne vous moquez pas d'objets de valeur ou d'utilitaires simples.

• Cas de bords de test
  Entrées nuls, collections vides, exceptions - ce sont des points de défaillance courants.

Réflexions finales

La rédaction du code Java testable ne consiste pas seulement à ajouter des tests - il s'agit de concevoir vos classes avec une testabilité à l'esprit. Utilisez l'injection de dépendance, favorisez la composition à l'instanciation et séparez proprement les préoccupations.

Avec Junit 5 et Mockito, vous obtenez des outils puissants pour:

• écrire des tests expressifs et lisibles
• Isoler les unités de comportement
• Simuler les dépendances en toute sécurité

Le résultat? Code qui est plus facile à changer, à déboguer et à faire confiance.

Fondamentalement, si vous ne pouvez pas le tester facilement, repensez la conception.

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!