top 12 mockito interview questions
Questions d'entretien Mockito les plus fréquemment posées pour briser l'entrevue moqueuse Mockito:
Dans notre tutoriel précédent, nous avons appris Méthodes de moquerie privées, statiques et nulles . Lisez le tutoriels de formation complets sur Mockito pour une compréhension claire du framework Mockito.
Cet article couvre les questions d'entretien typiques les plus fréquemment posées sur le cadre Mockito Mocking.
On s'attend à ce que chaque développeur ou QA connaisse les bases du Mocking afin d'écrire le plus de tests en boîte blanche (ou tests unitaires) avec facilité et de se moquer des dépendances pour une couverture de code améliorée et une plus grande confiance dans l'application.
Questions d'entrevue Mockito les plus populaires avec réponses détaillées
Vous trouverez ci-dessous les questions les plus fréquemment posées sur les cadres moqueurs.
Q # 1) Pourquoi avons-nous besoin de se moquer?
Répondre: Il existe de nombreux cas d'utilisation de moquerie qui facilitent les tests unitaires du code sous isolement et rendent le test hautement répétable et prévisible.
La moquerie est généralement requise lorsque:
à) Le composant testé a des dépendances qui ne sont pas encore implémentées ou l'implémentation est en cours.
Un bon exemple peut être un point de terminaison d'API REST qui sera disponible plus tard à un moment donné, mais vous l'avez consommé dans le code via une dépendance.
Maintenant que l'implémentation réelle n'est toujours pas disponible, vous savez vraiment la plupart du temps quelle est la réponse attendue de cette API. Les mocks vous permettent de tester ces types d'intégration.
b) Le composant met à jour l'état dans le système.
Exemple: Appels de base de données - vous ne voudriez pas mettre à jour votre base de données avec des données uniquement à des fins de test. Cela peut entraîner une corruption des données.De plus, la disponibilité de la base de données est un autre défi lorsque le test est exécuté.
Ainsi, pour éviter un tel comportement, les appels de base de données pourraient être simulés dans le composant testé. Il n'y a donc pas de couplage direct entre DB et le composant testé.
Q # 2) Différence entre doReturn et thenReturn.
Répondre: Mockito fournit deux syntaxes différentes pour créer des stubs comme:
- doReturn et puisReturn
- ne rien faire (pas alors rien)
- doThrow puisThrow
Ces deux méthodes installent des stubs et peuvent être utilisées pour créer / configurer des stubs et peuvent parfois être utilisées de manière interchangeable.
comment passer un tableau en tant que paramètre en java
Alors, en quoi ces deux diffèrent-ils?
à) La méthode thenReturn de stubbing est une méthode sécurisée de configuration des stubs. Cela signifie essentiellement qu'il effectue une vérification à la compilation par rapport aux types de retour que vous souhaitez également stuber.
Comprenons cela avec un exemple:
Supposons une méthode getItemDetails sur mockedItemService qui renvoie un objet de type ItemSku. Donc avec puisRetour, vous ne pourrez rien renvoyer d'autre que de type ItemSku mais avec doReturn, vous pouvez configurer le stub pour renvoyer quoi que ce soit et le test échouera (ou lèvera une exception) pendant l'exécution.
// travaux
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// lève une exception de temps de compilation
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// avec doReturn, la configuration du stub fonctionne car elle n'est pas sécurisée pour la compilation.
// ici, nous essayons de renvoyer un objet de type double qui fonctionne toujours et ne lève aucun avertissement de compilation.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) Une autre différence importante entre ces 2 façons de stub est pour les objets simulés, à part la sécurité de compilation, il n'y a pas beaucoup de différence.
Cependant, pour les objets Spied, le type de configuration de stub «thenReturn» ne fonctionnera pas, car il entraînera l'appel de la méthode réelle avant que la réponse stubbed ne soit renvoyée en tant qu'appel et non sur un Mock, mais sur Spy qui encapsule une instance d'objet réelle .
Alors supposons qu'il y ait un espion nommé spiedObject et il a une méthode testMethod qui renvoie un entier, puis pour configurer un stub sur celui-ci, vous devrez utiliser doReturn au lieu de thenReturn.
doReturn (10).when(spiedObject.testMethod());Q # 3) Quand et pourquoi utiliser un espion?
Répondre: Spy est un type de maquette partielle pris en charge par Mockito.
Cela signifie essentiellement qu'il s'agit d'un type d'instance où:
à) Lorsqu'aucune simulation n'est configurée, toute interaction sur l'espionnage entraîne l'appel des méthodes réelles. Mais cela vous permet toujours de vérifier les interactions avec l'objet espionné comme - une méthode a-t-elle été réellement appelée, combien de fois la méthode a été appelée, quels étaient les arguments à l'aide desquels la méthode a été appelée etc.
b) Cela vous donne la flexibilité de mettre en place des simulations partielles.
Par exemple, si vous avez un objet avec 2 méthodes - méthode1 et méthode2 et que vous voulez que la méthode1 soit appelée et que la méthode2 soit moquée. Les espions fournissent ce type de configuration.
Ainsi, la différence entre une maquette et un stub en termes simples est - une maquette est créée à partir d'un type et non à partir d'une instance alors qu'un stub enveloppe une instance réelle de l'objet de classe.
Q # 4) Pourquoi les méthodes statiques ne peuvent-elles pas être simulées avec Mockito?
VPN Japon gratuit
Répondre: Les méthodes statiques sont associées à la classe elle-même et non à une instance particulière de la classe. Cela signifie que toutes les instances / objets de la classe utilisent la même instance de la méthode statique.
Les méthodes statiques ressemblent davantage à du code procédural et sont principalement utilisées dans les systèmes hérités en général.
Les bibliothèques simulées créent généralement des simulations par création d'instances dynamiques au moment de l'exécution, soit via des interfaces, soit par héritage et comme la méthode statique n'est associée à aucune instance particulière, il n'est pas possible pour les frameworks moqueurs (comme mockito, easy mock, etc.) de se moquer des méthodes statiques.
Les frameworks tels que PowerMock qui prennent en charge les méthodes statiques effectuent une manipulation de bytecode au moment de l'exécution afin de simuler des méthodes statiques.
Q # 5) Quel est le besoin de vérifier que le simulacre a été appelé?
Répondre: La configuration d'un stub sur un objet simulé (ou une instance espionnée) ne garantit pas si la configuration stubbed a même été appelée.
Les matchers de «vérification», donnent la possibilité de valider si le stub qui a été mis en place a été réellement appelé ou non, combien de fois l'appel a-t-il été effectué, avec quels arguments la méthode stubbed a été appelée, etc.
En substance, cela nous permet de vérifier la configuration du test et le résultat attendu d'une manière plus robuste.
Q # 6) Qu'est-ce qu'un bon code testable?
Répondre:
Quelques points sur le code testable (ce qui signifie qui pourrait être facilement testé unitaire) comprennent:
- Réduction du nombre de dépendances ou couplage serré - Exemple: Les dépendances doivent être injectées plutôt qu'instanciées directement.
- Code qui adhère au SRP (principe de responsabilité unique) - Cela signifie essentiellement que la classe ne devrait pas avoir plusieurs raisons de changer. L'adhésion à SRP évite aux classes de créer une dépendance sur elle-même et maintient le code cohérent et propre.
- Utilisation moindre / minimale des méthodes statiques et des classes finales - Celles-ci indiquent généralement des odeurs de code et étaient principalement associées au code hérité.
Q # 7) Quelles sont les limites de Mockito?
Répondre: Mockito est un framework de choix pour la plupart des projets basés sur Java. Il est facile à mettre en œuvre, à lire et à comprendre.
Certains des inconvénients ou limitations en termes de fonctionnalité sont:
- Son incapacité à se moquer des méthodes statiques.
- Les constructeurs, les méthodes privées et les classes finales ne peuvent pas être moqués.
Q # 8) Quels frameworks peuvent prendre en charge les méthodes privées et statiques simulées?
Répondre: Des frameworks comme PowerMockito (extensions du framework Mockito), JMockit, etc. fournissent des moyens de se moquer des méthodes privées et statiques.
Q # 9) Méthodes par défaut de mocking / stubbing dans l'interface en Java 8.
Répondre: Avec l'implémentation par Java 8 des méthodes par défaut dans Interface, Mockito fournit un support prêt à l'emploi pour simuler ces méthodes par défaut. (Veuillez noter que ce support a été introduit à partir de Mockito 2).
Ces méthodes peuvent être simulées / stubblées comme toutes les autres méthodes d'une classe ou d'une interface.
Q # 10) Comment vérifier l'ordre des invocations de stub dans Mockito?
Répondre: Lorsque vous souhaitez vérifier l'ordre dans lequel les simulacres ont été appelés, Mockito's ' En ordre ”L'interface peut être utilisée.
Pendant le test, vous devez simplement configurer / créer un objet Inorder, répertoriant une liste d'objets fictifs sur lesquels l'ordre des simulations doit être vérifié (s'il existe plusieurs méthodes sur la même maquette et qu'il n'y a pas d'autre maquette qui nécessite pour être vérifié, il suffit de mentionner la classe fictive une seule fois).
Considérez le test donné ci-dessous qui définit un objet d'InOrder et mentionne 2 occurrences de mockDatabaseImpl
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } De plus, pour référence, lister le code de la méthode testée sera utile pour comprendre l'ordre d'exécution du test:
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); databaseImpl.getGrade(total); }Comme vu ci-dessus, databaseImpl appelle d'abord updateScores, puis appelle getGrade.
Donc, si vous écrivez un test unitaire à l'aide de Mockito, pour cela et que vous devez vous assurer de l'ordre des appels sur databaseImpl, reportez-vous au code de test et assurez-vous que les assertions sont faites selon l'ordre attendu.
Dans l'exemple ci-dessus, si je change l'ordre des assertions, le test échouera à l'exception de «VerificationInOrderFailure».
Après avoir modifié l'ordre d'assertion, le code ressemble à celui ci-dessous:
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } L'exécution de test ci-dessus lève une exception avec le type:
«VerificationInOrderFailure» org.mockito.exceptions.verification.VerificationInOrderFailure:
Vérification en cas d'échec de commande
Recherché mais pas invoqué:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
Q # 11) Renvoyer plusieurs valeurs contre des appels de méthode consécutifs
Répondre: Pour renvoyer des valeurs différentes pour plusieurs appels de la même méthode stubbed, Mockito propose 3 approches comme indiqué ci-dessous:
à) En utilisant des virgules séparées: Cela fonctionne avec thenReturn.
Par exemple , en prenant l'exemple de code ci-dessus, essayons de configurer un stub consécutif pour la méthode - getGrade qui renverra des valeurs différentes en fonction de la séquence d'itérations:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');Cela signifie que lorsque les méthodes getGrade sont appelées dans la méthode testée, la première invocation retournera «A», la seconde invocation retournera «B» et ainsi de suite.
b) Consécutif puis Retour: Il s'agit d'une approche enchaînée avec les instructions thenReturn. L'application d'appels chaînés au même exemple ressemblera à l'illustration ci-dessous.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) Retour consécutif: La dernière approche utilise doReturn dans le format chaîné comme ci-dessus.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())Q # 12) Quels sont les différents types de frameworks moqueurs et comment fonctionnent-ils?
meilleur nettoyeur de disque gratuit pour windows 10
Répondre: Les types de framework Mocking et leur fonctionnement sont expliqués ci-dessous.
Il existe en gros 2 catégories de frameworks moqueurs:
- Basé sur un proxy - Exemple, Mockito, EasyMock, etc.
- Basé sur le bytecode - Exemple, PowerMock, JMockit, etc.
Comparons ces deux cadres sur différents paramètres.
| Basé sur un proxy | Basé sur le bytecode | |
|---|---|---|
| Simplement | Plus simple et facile à utiliser | Peut impliquer une logique de configuration fictive complexe |
| Mode de création | Un proxy ou un faux objet qui ne nécessite pas réellement d'instance de classe / interface est créé | Il s'agit essentiellement de créer des objets et de manipuler au moment de l'exécution les instances pour le comportement simulé / stubbed |
| Fonctionnalité | Mocking classes et interfaces | En plus des classes et des interfaces, permet de se moquer des méthodes statiques, des classes finales, etc. |
| Dépendance Java | Pas très étroitement couplé aux versions java | Étant donné que ces frameworks impliquent une manipulation de bytecode, ils sont étroitement couplés et peuvent ne pas être compatibles avec les versions java. |
| Exemples | Mockito, EasyMock etc. | PowerMock, JMockit etc. |
Conclusion
Le contenu couvert dans cet article sert des discussions de base sur les cadres de mocking et en particulier la préparation des entretiens Mockito.
En plus d'acquérir une compréhension théorique des questions abordées, il convient également d'essayer de faire de vrais exemples de code qui rend l'apprentissage de ces cadres plus amusant et intéressant.
J'espère que vous avez apprécié toute la gamme de tutoriels de cette série Mockito.
Bon apprentissage.
Tutoriel PREV | PREMIER Tutoriel
lecture recommandée
- Questions et réponses d'entrevue
- Tutoriel Mockito: Framework Mockito pour la simulation dans les tests unitaires
- Quelques questions d'entretien intéressantes sur les tests de logiciels
- Questions et réponses d'entrevue de test ETL
- Questions d'entretien les plus fréquentes sur Oracle Forms and Reports
- Questions d'entrevue de test manuel du logiciel pour les professionnels expérimentés
- Questions les plus fréquentes sur les entretiens techniques Oracle Apps et Oracle SOA
- 25 meilleures questions et réponses d'entrevue de test Agile