mockito tutorial mockito framework
Un guide complet de Mockito Framework: Tutoriels Mockito pratiques
comparer deux fichiers sous linux et trouver les différences
Les tests unitaires sont une technique simple mais efficace pour gagner un bon niveau de confiance dans le code à expédier.
De plus, cela évite les problèmes de régression avec chaque morceau de code qui est archivé.
Avec une architecture de type micro-services (et même pour une structure simple impliquant des appels de base de données), des tests unitaires simples ne suffisent pas. Ce dont nous avons besoin, c'est de se moquer des dépendances et de tester la logique réelle de la méthode testée.
Liste de TOUS les didacticiels Mockito de cette série:
Tutoriel n ° 1: Mockito Framework pour la simulation dans les tests unitaires (Ce tutoriel)
Tutoriel n ° 2: Créer des simulacres et des espions dans Mockito
Tutoriel n ° 3: Différents types de matchers fournis par Mockito
Tutoriel n ° 4: Se moquer des méthodes privées, statiques et nulles à l'aide de Mockito
Tutoriel n ° 5: Top 12 des questions d'entretiens chez Mockito
************************************************* * *******************
Présentation des didacticiels de cette série Mockito
| Didacticiel # | Ce que vous apprendrez |
|---|---|
| Tutoriel n ° 1: | Mockito Framework pour la simulation dans les tests unitaires Apprenez à vous moquer avec Mockito - Un didacticiel Mockito complet pour les débutants avec des exemples de code. Apprenez le cadre de simulation pour la simulation dans les tests unitaires. |
| Tutoriel n ° 2: | Créer des simulacres et des espions dans Mockito Mocks and Spies sont des types de tests doubles, qui sont utiles pour écrire des tests unitaires. Les deux sont expliqués dans ce tutoriel Mockito Spy avec des exemples de code. |
| Tutoriel n ° 3: | Différents types de matchers fournis par Mockito Apprenez à utiliser différents types de matchers fournis par Mockito. Les matchers sont comme des jokers où au lieu d'une entrée / sortie spécifique, vous spécifiez une plage d'entrée. L'argument et la vérification sont les deux types de Matchers dans Mockito qui sont expliqués en détail ici. |
| Tutoriel n ° 4: | Se moquer des méthodes privées, statiques et nulles à l'aide de Mockito Apprenez à se moquer des méthodes privées, statiques et nulles dans Mockito avec des exemples. Apprenez à se moquer des méthodes privées et statiques par le cadre de test unitaire PowerMockito. |
| Tutoriel n ° 5: | Top 12 des questions d'entretiens chez Mockito Mockito Interview Questions et réponses avec des exemples de code. Cela vous aidera à réussir toute interview de Mockito Mocking Framework. |
Commençons par le premier tutoriel de cette série !!
Ce que vous apprendrez:
- Mocking dans les tests unitaires
- Types / catégories de tests doubles
- Différents cadres moqueurs
- Code source
- Conclusion
- lecture recommandée
Mocking dans les tests unitaires
Mocks / Stubs est un terme que les gens entendent couramment lors de la création de tests unitaires en particulier.
Alors, qu'est-ce que la moquerie? En termes simples, il ne s'agit que de fournir une instance contrôlée ou une implémentation de dépendance dont dépend le code testé pour tester sa logique de base.
La raison pour laquelle je l'ai mentionné comme instance contrôlée est que le comportement de la dépendance peut être programmé ou contrôlé comme souhaité pour la méthode ou le système testé.
Pour l'expliquer de manière schématique, prenons un exemple d'une application commerciale ou de commerce électronique. Presque tous ces types d'applications ont principalement 3 couches, c'est-à-dire Interface utilisateur, couche métier et couche d'accès aux données (qui communique avec le magasin de données sous-jacent)
En référence au diagramme ci-dessus, la couche métier a 3 dépendances, à savoir la couche d'accès aux données et 2 autres services qui sont le service 1 et le service 2.
Regardez les choses de cette façon - Une application comme google maps peut avoir des dépendances sur un
- Les magasins de données réels comme MySQL ou toute autre base de données sans SQL qui stocke les données cartographiques.
- Un service externe comme CoordinateService qui fournit les latitudes et les longitudes d'un emplacement.
- Un service externe comme le service de trafic qui fournit des informations de trafic en temps réel pour une paire de coordonnées donnée.
Ainsi, si quelqu'un essaie de valider la logique métier de base à l'aide du test unitaire, jusqu'à ce que et à moins d'avoir des implémentations fonctionnelles de ces dépendances, les tests ne peuvent pas être exécutés.
Les simulacres viennent à la rescousse dans ces situations, où quelle que soit votre dépendance opérationnelle ou non, vous êtes toujours assuré d'exécuter votre logique métier avec une réponse programmée pour la dépendance qui est appelée à partir du code testé.
Types / catégories de tests doubles
Mock est essentiellement un type de «Test Double» - c'est un jargon technologique. «Test Double» signifie essentiellement un objet qui est remplacé par une instance ou une dépendance d'objet réel équivalente.
Il existe différents types de tests doubles comme mentionné ci-dessous:
# 1) Faux:
Un faux est une implémentation fonctionnelle similaire à une vraie dépendance, à l'exception du fait qu'elle est locale au système testé.
Exemple: Au lieu de toucher une vraie base de données de production, le test utilise une simple collection / en mémoire pour stocker les données.
# 2) Stubs:
Les stubs sont des réponses préconfigurées lorsqu'une dépendance est appelée à partir du système testé.
# 3) Espions:
Comme son nom l'indique, il s'agit en fait de l'appel de fonction réelle (dépendance) avec un mécanisme d'observation. Après l'appel, il peut être vérifié si l'appel a été réellement déclenché ou non avec les paramètres.
# 4) Se moque:
Les simulacres sont des instances spéciales d'objets, sur lesquelles des réponses stubbed / préconfigurées peuvent être spécifiées. Le fait que le simulacre ait été appelé peut être vérifié comme une affirmation dans le test.
Par exemple:
Il existe une fonction de générateur de rapports qui envoie un e-mail à une adresse spécifiée lors de l'exécution.
Comme nous ne voulons pas envoyer de courrier électronique réel, encore et encore, pendant les tests, le service EmailService est simulé (et la méthode de courrier électronique qui envoie le courrier électronique est configurée pour ne rien faire lorsqu'elle est appelée). À la fin du test, nous pouvons simplement vérifier que la méthode d'envoi d'e-mail du service de messagerie a été appelée via l'objet simulé.
Différents cadres moqueurs
Presque tous les langages fournissent différents types de cadres moqueurs. Nous allons écrire un exemple de code à l'aide de Mockito, un framework de simulation open source pour Java.
Anatomie d'un test unitaire simple avec dépendance simulée. Supposons que nous essayions de tester unitaire une application qui calcule le total des notes d'un élève dans toutes les matières et l'écrit dans DB.
public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for (int score: scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } Maintenant, si nous voulons écrire un test unitaire pour la méthode - CalculateSumAndStore, alors nous pourrions ne pas avoir une réelle implémentation d'une base de données pour stocker le total. Dans ce cas, nous ne pourrons jamais tester cette fonction unitaire.
Mais avec des simulations en place, nous pouvons simplement passer un Mock pour le service de base de données et valider le reste de la logique
Exemple de test comme indiqué ci-dessous:
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); } Nous avons vu dans le test ci-dessus, nous avons fourni un objet mockDatabase à la classe parente (pour la méthode testée) et nous avons mis en place une réponse stub pour l'objet mockedDatabase - Ligne n ° 6 ci-dessus (Mockito.doNothing (). When (mockDatabase) .updateScores ('student1', 220);)
Les points importants à noter ci-dessus sont:
#1) L'objet simulé doit configurer des réponses stubbed pour toutes les méthodes qui seront appelées lors de l'exécution de la fonction.
#deux) Les paramètres spécifiés lors de la création du stub peuvent être spécifiques ou génériques.
Exemple dans le cas ci-dessus - nous avons spécifié les paramètres de la méthode updateScores comme «étudiant1» et 220 parce que nous savons que ce sont les entrées exactes avec lesquelles notre méthode va être appelée.
# 3) Lors de la vérification, nous validons les éléments suivants:
- La méthode mockDatabase.updateScores a été appelée.
- Les arguments étaient «étudiant1» et 220 respectivement.
- La méthode updateScores a été appelée 1 fois.
Essayons maintenant de modifier un peu ce code de test et voyons ce qui se passe:
Je changerai l'argument dans la configuration fictive de «student1» à anyString (Mockito fournit un matcher standard nommé anyString ()) & 220 en anyInteger (Mockito fournit un matcher standard nommé anyInt () et il correspond à n'importe quelle valeur entière)
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); } Essayez à nouveau d'exécuter le test et le test doit toujours être vert.
(Essayons maintenant de modifier la vérification / les assertions et de modifier l’un des arguments.
Modifions 220 à 230. On s'attend maintenant à ce que le test échoue car ce n'est pas l'argument attendu avec lequel la databaseUpdate doit avoir été appelée.
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } Après avoir exécuté le test, reportez-vous aux journaux d'erreurs comme indiqué ci-dessous (il indique clairement que les arguments réels ne correspondent pas à ceux attendus).
Les arguments sont différents! Voulait:
mockDatabase.updateScores («étudiant1», 230);
-> sur com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)
L'appel réel a différents arguments:
mockDatabase.updateScores («étudiant1», 220);
Code source
Interface - IDatabase.java
public interface IDatabase { public void updateScores(String studentId, int total); }Classe en cours de test - StudentScoreUpdates.java
public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } } Classe de tests unitaires - StudentScoreUpdatesUnitTests.java
public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } } Conclusion
Ce que nous avons vu jusqu'à présent est un exemple très basique et simple de configuration Mock à l'aide du framework Mockito de Java.
Pour près de 60 à 70% des tests unitaires impliquant des simulations, les tests devraient avoir une structure similaire. Mockito fournit beaucoup de configuration / support avancé pour des besoins de simulation étendus, injectant des instances simulées à l'aide de l'injection de dépendances, permet aux Spies d'espionner réellement un appel de méthode réel et de vérifier les appels.
Notre prochain tutoriel vous expliquera plus en détail le concept des mocks et des espions dans Mockito.
lecture recommandée
- Top 12 des questions d'entrevue Mockito (entretien Mocking Framework)
- Tutoriels Eclipse détaillés pour les débutants
- Comment configurer le cadre de test Node.js: Tutoriel Node.js
- Ecrire des tests unitaires avec Spock Framework
- Les différences entre les tests unitaires, les tests d'intégration et les tests fonctionnels
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)
- Tutoriel sur les tests destructifs et les tests non destructifs
- Test fonctionnel vs test non fonctionnel