Mockito n'aime pas les espions (spy) (3/3)

Vous reprendrez bien un petit Mockito... Précédemment nous avons vu comment créer un mock  et comment l'utiliser . Il reste encore quelques aspects à voir comme les spy et la syntaxe BDD.

Qu'est ce qu'un objet espion (spy) ? 
Dans James Bond, les espions aiment les cocktails comme le Mojito, mais Mockito n'aime pas forcément les espions...

Un mock est un objet postiche qui simule le fonctionnement d'un autre objet. Quand vous utilisez un mock il n'y a aucun lien avec l'objet initial.

Un spy fonctionne différemment et ajoute juste une surcouche à un objet réel. Par défaut ce sont les méthodes réelles de l'objet qui sont appelées mais vous pouvez les "stubber" (francisation de stub), c'est à dire que vous pouvez surcharger leur comportement.

Je disais que Mockito n'aime pas les spy, mais la vérité est plutôt que les spy ne sont pas encouragés. Ils ne devraient être réservés qu'à des cas particuliers : code legacy, simulation méthode interne... C'est un concept qu'il est bon de connaître mais qui doit être utilisé avec parcimonie.

Comment définir un spy ? 
Pour créer un spy, vous pouvez utiliser la méthode spy de Mockito, mais comme pour les mocks, l'annotation  @Spy est à mon sens plus élégante.

Dans mon exemple ci dessous, la classe à tester est un spy et mon but est de mocker la méthode interne checkArticle

@RunWith(MockitoJUnitRunner.class)

public class BlogArticleServiceImplCas4Test {
    @InjectMocks
    @Spy
    private BlogArticleService blogArticleService = new BlogArticleServiceImpl();
    @Mock
    private BlogExporterService mockElogExporterService;


    @Test
    public void writeArticleShouldNotPublishAndBroadCastWhenCheckFailed(){
        when(blogArticleService.checkArticle(any(Article.class)))

             .thenReturn(false);
        assertThat(blogArticleService.write("title", "my new content")).isEqualTo(false);
        verifyZeroInteractions(mockElogExporterService);
    }

}

Parfois nous pouvons avoir des problèmes pour stubber la méthode d'un spy et vous pouvez être amené à revoir la syntaxe pour déclarer le stub. Classiquement nous faisons

when(blogArticleService.checkArticle(any(Article.class))).thenReturn(false);

Si il y a un problème dans l'appel de la méthode réelle vous pouvez utiliser cette syntaxe

Mockito.doReturn(false).when(blogArticleService).checkArticle(any(Article.class));

Mockito et BDD
Si vous faites du BDD, le mot clé when peut vous perturber.

@Test
public void writeArticleShouldPublishAndBroadCast(){
   when(mockElogExporterService.socialBroadcast(any(Article.class)))

            .thenReturn(3);
   
   assertThat(blogArticleService.write("title", "my new content").isEqualTo(true);
}

En BDD les tests sont structurés suivant un pattern given/when/then. Avec Mockito,  vous pouvez utiliser la méthode given au lieu de when . Ce qui donne

@Test
public void writeArticleShouldPublishAndBroadCast(){
   //given
   given(mockElogExporterService.socialBroadcast(any(Article.class)))

           .willReturn(3);
   //when

   boolean result = blogArticleService.write("title", "my new content");
   //then
   assertThat(result).isEqualTo(true);
}

Pour conclure

J'espère vous avoir donné un bon aperçu du fonctionnement de Mockito dans mes 3 articles sur le sujet. Personnellement je suis fan de cette API qui permet d'écrire des tests très rapidement et très simplement. Si vous voulez en savoir plus je vous laisse lire la documentation

Merci à Agnes Crepet pour sa relecture