JUnit - Test d'une méthode qui appelle à son tour quelques méthodes supplémentaires

Question

C'est mon doute sur ce que nous considérons comme une "unité" lors des tests unitaires.

dire que j'ai une méthode comme celui-ci,

public String myBigMethod() 
     { 
     String resultOne = moduleOneObject.someOperation(); 
     String resultTwo = moduleTwoObject.someOtherOperation(resultOne); 
     return resultTwo; 
     } 

(j'ai des tests unitaires écrits pour someOperation() et someOtherOperation() séparement)

et ce myBigMethod() intègre un peu ModuleOne et ModuleTwo en les utilisant comme ci-dessus,

alors, est-ce que la méthode "myBigMethod()" est toujours considérée comme une "unité"?

Dois-je écrire un test pour ce "myBigMethod()"? Dire que j'ai écrit un test pour myBigMethod() ... Si testSomeOperation() échoue, cela provoquerait également l'échec de testMyBigMethod() ... Maintenant, l'échec de testMyBigMethod() pourrait montrer un défaut ... emplacement correct du bug. Une cause causant l'échec de deux tests ne me semble pas si bonne. Mais donno s'il y a un meilleur moyen ...? Y a-t-il ?

Merci!

Answer 1

Le test pour myBigMethod() devrait tester la combinaison des résultats des deux autres méthodes appelées. Donc, oui, il devrait échouer si l'une ou l'autre des méthodes dépend de l'échec, mais cela devrait être testé plus. Il devrait y avoir un cas où someOperation() et someOtherOperation() fonctionnent correctement, mais myBigMethod() peut encore échouer. Si ce n'est pas possible, il n'est pas nécessaire de tester myBigMethod().

Answer 2

Vous souhaitez tester la logique de myBigMethod sans tester les dépendances.

Il ressemble à la spécification de myBigMethod est:

1. Appel moduleOneObject.someOperation
2. passer le résultat dans moduleTwoObject.someOtherOperation
3. Retour le résultat

La clé de test juste ce comportement consiste à rompre les dépendances sur moduleOneObject et moduleTwoObject. Typiquement ceci est fait en passant les dépendances dans la classe à tester dans le constructeur (injection du constructeur) ou en les définissant via les propriétés (injection de setter).

La question n'est pas seulement académique car en pratique, moduleOneObject et moduleTwoObject pourraient sortir et frapper des systèmes externes tels qu'une base de données. Un vrai test unitaire ne frappe pas les systèmes externes car cela en ferait un "test d'intégration".