im essayant de tester une classe d'une classe dans un code Java que j'ai hérité.
problème est qu'il provient d'une classe qui fait partie de la demande de la société FRAMWWork. Lors de la construction, la classe de base fait toutes sortes de choses «intelligentes», initialisant les connexions à toutes sortes de services nécessaires au moment de l'exécution.
Mais pour des fins de test unitaire, je n'ai pas besoin de cela. J'ai juste besoin de créer une instance de la classe dérivée, puis je peux l'excercer. Si un test a spécifiquement besoin d'une partie de la hiérarchie, je peux les moquer de.
Alors, comment puis-je casser cette dépendance?
4 Réponses :
Vous avez donc une classe de base et une classe étendue. Voyez si vous pouvez refactoriser la classe étendue pour ne plus étendre la classe de base, mais utilisez-la à la place. Alors, où vous avez appelé le premier Si vous avez vraiment besoin d'étendre la classe de base pour remplacer quelque chose, extrayez la fonctionnalité vers une troisième classe et apportez le proxy de la classe prolongée. La classe étendue ne fait rien d'autre que des méthodes d'appel sur la troisième classe. E.g. De cette façon, vous pouvez tester la réelle implémentation, sans instantiquer la classe de base. parent :: foobar () , vous appelez maintenant this.baseinstance.foobar () . De cette façon, vous pouvez injecter une autre baseInstance à des fins de test.
Héritage peut être si fragile.
L'héritage est-elle une exigence? Toutes ces choses "intelligentes" que la classe de base fait (par exemple, établir des connexions) sont des choses qu'un moteur d'injection de dépendance fournirait normalement.
Votre classe sonne comme si cela seraient mieux à la fois d'un test et d'un point de vue de l'exécution si vous trouvez un moyen de ne pas hériter et d'obtenir ses dépendances satisfaites par un moteur DI. Possible?
Nous avons eu un problème similaire.L'emples de classes de niveau-cadre et de dépendances. Nous avons résolu-le en utilisant di
Je pense que Guice est le meilleur di Cadre, le printemps est trop Java 1.4.
Java 1.4? Avec configuration par annotation? Pas ça. Il serait juste de souligner que cela a été conçu comme une réponse aux lacunes de J2EE et EJB 2.0, mais «Trop Java 1.4» n'est pas correcte. Guice peut être un bon di-cadre, mais le printemps est beaucoup plus que cela. C'est la persistance, la messagerie, la télécommande et les lots plus construits sur DI et AOP.
Je suis d'accord avec les autres qui suggèrent que l'injection de dépendance est la voie à suivre à long terme. En tant que pirate de courte durée, vous pouvez essayer d'introduire un drapeau "global" qui désactive le code d'initialisation intelligent pour les tests.