Ne Jamais dire Jamais

Des tests, vous en reprendrez bien un bocal ?

Lorsque l'on teste une méthode qui appelle un service en utilisant un mock, il est facile de vérifier qu'on appelle la bonne méthode avec les bons paramètres en utilisant la méthode verify de mockito.
Mais qu'en est-il lorsque l'on insère une condition qui implique que l'on ne doit pas appeler la méthode. La tentation est grande d'utiliser un verify avec le mode de vérification never.

Exemple avec scalatest :

Le code à tester

def addinfo(user: User): = {
	user.info foreach(i => infoManager.addInfo(user.name, i)) 
}

Je vérifie ci dessous que je ne vais pas appeler la méthode addInfo d'infomanager

 "do not add information for a new user without info" in new Fixture {
    val service = ServiceFactory.create()
    val user = UserFactory.create(service.name).copy(info = None)

	userManager.addInfo(user, service)

	verify(infoManager, never()).addInfo(user.name, user.info)

    }    

Je me suis toujours posé la question de la pertinence de ce test, car imaginons que je transforme le code de la façon suivante.

def addinfo(user: User): = {
	infoManager.addInfo(user.name, "What ?") 
}

Lorsqu'on lance le teste précédent, le test passe, si user.info bien sûr n'est pas égal à "What ?".
Lors de l'écriture du test, et si on le réalise en TDD, il y a peu de chance de tomber dans ce piège. Mais tout au long du projet, lorsqu'on va remanier le code, il y a des chances que l'on arrive à un cas similaire. Et dans ce cas le test en question ne teste plus rien. C'est toujours périlleux de tester qu'on ne fait jamais quelque chose. Heureusement il y a verifyNoInteractions qui permet de vérifier qu'on a jamais d'interaction avec l'objet.

Le même test avec verifyNoInteractions

 "do not add information for a new user without info" in new Fixture {
    val service = ServiceFactory.create()
    val user = UserFactory.create(service.name).copy(info = None)

	userManager.addInfo(user, service)

	verifyNoInteractions(infoManager)

    }    

On peut aussi utiliser verifyNoMoreInteractions lorsque l'on a dans le code d'autres interactions avec l'objet.

En conclusion pour ma part j'éviterais le never qui peut être délicat lors de refactoring au profit du verifyNoInteractions en n'oubliant pas l'avertissement de la documentation de ne pas systématiser l'utilisation de la méthode verifyNoMoreInteractions.