Est-ce une utilisation appropriée de la méthode de réinitialisation de Mockito?

J'ai une méthode privée dans ma classe de test qui construit un Barobjet couramment utilisé . Le Barconstructeur appelle la someMethod()méthode dans mon objet simulé:

private @Mock Foo mockedObject; // My mocked object
...

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
}

Dans certaines de mes méthodes de test, je souhaite vérifier someMethodque ce test particulier a également été invoqué. Quelque chose comme ce qui suit:

@Test
public void someTest() {
  Bar bar = getBar();

  // do some things

  verify(mockedObject).someMethod(); // <--- will fail
}

Cela échoue car l'objet simulé a été someMethodinvoqué deux fois. Je ne veux pas que mes méthodes de test se soucient des effets secondaires de ma getBar()méthode, donc serait-il raisonnable de réinitialiser mon objet fictif à la fin de getBar()?

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
  reset(mockedObject); // <-- is this OK?
}

Je demande, parce que la documentation suggère que réinitialiser des objets fictifs est généralement révélateur de mauvais tests. Cependant, cela me convient.

Alternative

Le choix alternatif semble appeler:

verify(mockedObject, times(2)).someMethod();

ce qui à mon avis oblige chaque test à connaître les attentes de getBar(), sans aucun gain.

Je crois que c'est l'un des cas où l'utilisation reset()est ok. Le test que vous écrivez teste que "certaines choses" déclenchent un seul appel someMethod(). L'écriture de la verify()déclaration avec un nombre différent d'invocations peut prêter à confusion.

• atLeastOnce() permet de faux positifs, ce qui est une mauvaise chose car vous voulez que vos tests soient toujours corrects.
• times(2)empêche le faux positif, mais donne l'impression que vous attendez deux invocations plutôt que de dire "je sais que le constructeur en ajoute un". De plus, si quelque chose change dans le constructeur pour ajouter un appel supplémentaire, le test a maintenant une chance d’être faussement positif. Et supprimer l'appel entraînerait l'échec du test, car celui-ci est maintenant faux, et non ce qui est testé.

En utilisant reset()la méthode d'assistance, vous évitez ces deux problèmes. Cependant, vous devez faire attention à ce que cela ne réinitialise pas non plus les attaques que vous avez effectuées. Soyez donc averti. La principale raison reset()est découragée est d'empêcher

bar = mock(Bar.class);
//do stuff
verify(bar).someMethod();
reset(bar);
//do other stuff
verify(bar).someMethod2();

Ce n’est pas ce que le PO essaie de faire. Je suppose que l’OP a un test qui vérifie l’invocation dans le constructeur. Pour ce test, la réinitialisation permet d’isoler cette action unique et son effet. C'est l'un des rares cas avec qui reset()peut être utile comme. Les autres options qui ne l'utilisent pas ont toutes des inconvénients. Le fait que l'OP ait écrit cet article montre qu'il réfléchit à la situation et n'utilise pas aveuglément la méthode de réinitialisation.

Les utilisateurs de Smart Mockito n’utilisent guère la fonction de réinitialisation, car ils savent que cela pourrait être le signe de mauvais tests. Normalement, vous n'avez pas besoin de réinitialiser vos modèles, créez-en de nouveaux pour chaque méthode de test.

Au lieu de reset()penser à écrire des méthodes de test simples, petites et ciblées sur des tests longs et sur-spécifiés. La première odeur de code potentielle est reset()au milieu de la méthode de test.

Extrait des documents mockito .

Mon conseil est que vous essayez d'éviter d'utiliser reset(). À mon avis, si vous appelez deux fois à une méthode, cela doit être testé (il s’agit peut-être d’un accès à une base de données ou d’un autre processus long dont vous souhaitez prendre soin).

Si cela vous est égal, vous pouvez utiliser:

verify(mockedObject, atLeastOnce()).someMethod();

Notez que ce dernier risque de générer un résultat faux, si vous appelez someMethod depuis getBar, et non après (il s’agit d’un comportement incorrect, mais le test n’échouera pas).

Absolument pas. Comme c'est souvent le cas, la difficulté que vous rencontrez lors de la rédaction d'un test vierge est un signal d'alarme majeur pour la conception de votre code de production. Dans ce cas, la meilleure solution consiste à refactoriser votre code afin que le constructeur de Bar n'appelle aucune méthode.

Les constructeurs doivent construire et non exécuter la logique. Prenez la valeur de retour de la méthode et transmettez-la en tant que paramètre constructeur.

new Bar(mockedObject);

devient:

new Bar(mockedObject.someMethod());

Si cela devait entraîner la duplication de cette logique à plusieurs endroits, envisagez de créer une méthode fabrique pouvant être testée indépendamment de votre objet Bar:

public Bar createBar(MockedObject mockedObject) {
    Object dependency = mockedObject.someMethod();
    // ...more logic that used to be in Bar constructor
    return new Bar(dependency);
}

Si cette refactorisation est trop difficile, utiliser reset () est un bon moyen de contourner le problème. Mais soyons clairs: cela indique que votre code est mal conçu.