Classes utilitaires de test unitaire
Nous avons tous des classes utilitaires, qui ne contiennent que des méthodes statiques, à utiliser à partir de différentes sources. Maintenant, il peut y avoir deux approches qui peuvent être prises pour tester ce morceau de code.
Approche 1:
Avoir des tests unitaires séparés pour les classes utilitaires. Où qu'ils soient appelés, simulez leur interaction en utilisant un cadre de test qui le prévoit, tel que PowerMock. Cela traite essentiellement la classe d'utilité comme un composant distinct du système, qui doit être testé et entretenu individuellement.
Approche 2:
N'écrivez pas de tests unitaires pour les classes utilitaires. Cependant, les tests qui sont écrits pour vos autres classes de base qui interagissent avec cette classe utilitaire, laissent cette interaction se produire, ce qui garantira intrinsèquement que le code écrit dans cette classe utilitaire est correctement testé pour différents cas d'utilisation. Si quelque chose se casse, les tests des autres composants devraient pouvoir l'attraper.
Veuillez partager vos réflexions sur l'approche qui est préférable, ou s'il y a une autre manière dont les gens s'y prennent.
Je pense qu'il y a un gros malentendu sur les classes "utilitaires". Ce n'est pas parce que vous rendez une classe "statique" qu'elle en fait une classe utilitaire. Si votre classe utilitaire statique a des dépendances (qui peuvent se manifester dans d'autres classes "utilitaires" statiques), elle introduit des effets secondaires ou son comportement ne peut pas être complètement contrôlé par ses entrées n'est pas une classe utilitaire.
Il n'est pas nécessaire de se moquer des vraies classes d'utilité car leur sortie est toujours déterministe en fonction de leurs entrées.
Le test unitaire consiste à instancier une petite partie de votre application (une unité) de manière isolée afin que vous puissiez (potentiellement) tester tous les chemins de code au sein de cette unité. Les dépendances moqueuses réalisent cet isolement. Si une classe utilitaire rompt l'isolement, ce n'est pas une classe utilitaire car une classe utilitaire est censée être isolée par définition.
Donc, dans une application, il ne faut jamais vouloir ou devoir se moquer des classes utilitaires. Les classes qui, selon vous, doivent être moquées doivent être transformées en classes instanciables de première classe et doivent être transmises à l'unité en tant que dépendance (voir Injection de dépendance ). Ces dépendances peuvent alors être facilement moquées afin que l'unité puisse être testée isolément.
À mon avis, il est ridicule de se moquer d'une dépendance à une méthode d'utilité statique pour des choses telles que le fractionnement de chaînes.
Oui, si la méthode de séparation est erronée, cela peut entraîner des échecs parasites dans les tests de méthodes qui ne concernent pas le fractionnement de chaînes. Mais ce n'est pas le but d'une suite de tests. La suite de tests doit réussir à 100%, point final. Si ce n'est pas le cas, vous réparez ce qui est cassé et répétez jusqu'à ce qu'il réussisse à 100%. Si la classe d'utilité de chaîne est rompue, elle devrait immédiatement provoquer un échec dans un test qui est sur la fonctionnalité de chaîne. Vous corrigez cette fonctionnalité, puis tous les échecs disparaissent, vous n'avez donc même plus besoin de regarder les cas de test qui échouent.
En d'autres termes, OUI, écrivez des tests pour les méthodes utilitaires. NON, n'essayez pas de les dissocier des autres tests. Supposons simplement que les fonctions utilitaires triviales fonctionnent correctement, comme le vérifient leurs propres tests. Faire quoi que ce soit de plus est plus d'effort sans aucun gain.