8
votes

Comment remplacer le comportement du printemps @Autowired

Un petit fond:

J'utilise le printemps 2.5, et spécifiquement le printemps IOC et les annotations.

J'utilise @autowired dans mon code (la mise en forme automatique est effectuée par type) et utilisez @Component pour exposer des classes au câblage automatique.

La situation décrite ci-dessous se posait alors que j'ai essayé de tester mon code.

maintenant au problème:

Remarque: j'utilise un contexte de printemps différent pour l'environnement de test.

J'ai une classe foo qui est @autowired mais dans le contexte de test, je veux utiliser une classe différente du même type simfoo (étend foo ).

La configuration du ressort du cours échoue automatiquement en raison de plusieurs options pour l'injection de dépendance de la classe FOO ( foo et simfoo correspondant à la vérification de type).

Je cherche un moyen d'injecter le grain de test au lieu du haricot d'origine.

Je m'attendais à ce que le ressort permettait d'utiliser le fichier de configuration contextuelle pour remplacer une injection de haricot ou pour commander du ressort de ne pas avoir la mise au point de haricot spécifique.

mais

Toutes ces options semblent exister uniquement pour les haricots définis à l'origine dans le fichier de configuration du contexte de printemps.


0 commentaires

3 Réponses :


7
votes

Utilisez RéflexionTestutilles Pour définir manuellement la maquette à la place de la dépendance autonome (à cette fin, votre simulacre ne doit pas être géré le printemps, de sorte qu'aucune ambiguïté n'existe)


1 commentaires

C'est une bonne solution lorsque vous n'avez pas le même instance injecté à plusieurs classes - mais dans un grand projet où une classe agit en tant que fournisseur de services (c'est un singleton) et est injecté à de nombreuses classes, j'espère qu'il y a plus de plus facile / meilleure solution pour éviter d'injecter chaque classe qui utilise l'original



2
votes

Je sais que cette question est assez ancienne mais une réponse peut encore être utile pour les autres.

Puisque vous ne voulez probablement pas mélanger à la fois FOO et MockFoo dans votre contexte, je suggère de supprimer FOO de la numérisation du composant. Cela pourrait être fait par exemple en spécifiant Inclure / exclure les filtres sur le . .

Toutefois, si vous mettez en œuvre des tests d'unités, je préfère suggérer d'utiliser un contexte de printemps et de simplement mettre en œuvre des tests d'unité «pure» en injectant des maquettes des dépendances manuellement, de sorte que vous ne testez qu'une seule classe. Cela peut être réalisé plus facilement en utilisant un cadre moqueur comme Mockito .


0 commentaires

2
votes

Je suis d'accord avec Didier. Voici un exemple de la manière dont vous pouvez exclure les implémentations que vous souhaitez vous moquer dans votre contexte d'application de test.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:/applicationContext-test.xml"})
public class MyTest {....}


1 commentaires

Bonne réponse, j'irais vraiment avec celui-ci. N'oubliez pas que vous pouvez toujours utiliser @qualifier (Nom = "Onesbean") sur votre objectif injecté et @Resource (Nom = "Onesbean") sur le terrain où vous voulez que l'instance de haricot spécifique soit injectée.