Tests avancés avec Mockito

1.1 Bibliothèque Mockito

Aujourd'hui, nous allons nous familiariser avec les tests avancés. Plus précisément, avec la bibliothèque Mockito . Ne pensez même pas à sortir de cette affaire.

Premièrement, cette bibliothèque est un standard dans Spring testing . Ce qui est en fait la norme dans l'industrie du développement backend Java.

Deuxièmement, vous devrez écrire des tests pour votre code Spring . La seule façon de comprendre que le backend que vous avez écrit fonctionne comme il se doit est d'appeler les méthodes de son API . Et le faire avec des tests est 10 fois plus facile que sans eux. Vous verrez par vous-même.

Vous pouvez ajouter la bibliothèque Mockito à la vôtre pom.xmlen utilisant le code :

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

L'intégralité du code source du projet Mockito est disponible sur GitHub .

1.2 Objets factices

Alors, qu'est-ce que ce Mockito et pourquoi est-il si bon ?

Dans le processus de développement et de développement des tests, il était très souvent nécessaire de glisser une sorte de "stub" dans le code au lieu d'un objet réel.

Par exemple, le code qui fonctionne avec la base de données est testé et y change quelque chose. Il est bon qu'avant chaque test l'état de cette base de données soit le même (sinon les tests seront différents). Et j'aimerais que la base soit plus simple afin de faire reculer rapidement ces états.

Ou, par exemple, vous testez un code qui envoie des SMS utiles. Et pour les publipostages, il utilise une sorte de passerelle SMS payante. Ce serait bien d'y glisser une passerelle virtuelle pour tester le code, histoire de ne pas envoyer des centaines de SMS à des personnes incompréhensibles.

Ou votre code demande des données à d'autres serveurs Web qui ne sont tout simplement pas disponibles sur le serveur de test. Ou vous écrivez un code pour les paiements en ligne qui doit être testé 50 fois, et seulement ensuite autorisé à être utilisé dans de vrais canaux financiers.

Je pense que vous comprenez ... Les objets virtuels, ou comme on les appelle aussi des objets stub, sont une chose très utile.

Et voici la difficulté - Java a un typage statique. Cela signifie que pour ReadDatabaseaffecter une référence à un objet à une variable au lieu d'un objet de type VirtualDatabase, vous devez hériter de la classe VirtualDatabasede RealDatabase.

Ensuite, il s'avère que la classe a RealDatabaseun tas de méthodes et de variables privées qui stockent des références à d'autres objets réels, et vous ne pouvez pas écrire un stub normal de cette façon. En théorie c'est bien, mais en pratique c'est une impasse.

Et voici venir à la rescousse ( vous pouvez lireDynamicProxy plus en détail ), qui est apparu dans Java 5. Il vous permet de créer des objets virtuels dont le compilateur ne se plaint pas.

Ces objets virtuels sont appelés mocks (du mot mock - mise en page). La bibliothèque Mockito a pu porter le travail avec ces maquettes à une hauteur sans précédent. D'où, soit dit en passant, le nom de la bibliothèque.

1.3 @ExtendWith annotation

La bibliothèque Mockito fonctionne très bien avec JUnit, elle peut même être considérée comme une extension de celle-ci.

Il existe deux façons d'activer la bibliothèque Mockito dans vos tests unitaires. La première consiste à ajouter une annotation spéciale :

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

La deuxième façon est d'activer son travail en appelant la méthode openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Le plus souvent, vous verrez la première option, mais parfois il est utile de savoir qu'il en existe une deuxième.