Je suis nouveau dans le cadre de printemps et j'ai une question sur ses capacités d'injection de dépendance à l'aide du contexte de printemps.
C'est la classe que j'essaie d'écrire un test d'intégration pour: P>
<bean id="userService" class="be.kdg.coportio.services.UserService">
<property name="validator" ref="validator"/>
<property name="userRepository" ref="userRepository"/>
<property name="encryptor" ref="encryptor"/>
<property name="mailService" ref="mailService"/>
</bean>
5 Réponses :
dans votre méthode @Before code>, assurez-vous de réinitialiser vos objets simulés. @Before
public void setup(){
Mockito.reset(validator);
}
Pour une raison quelconque, l'un des tests est maintenant fixé, mais les autres échouent toujours (même message qu'avant). J'ai mis 4 lignes dans la méthode de configuration comme ceci: Mockito.Reset (userservice.gevalidator ()); Peut-être que ça échoue parce que j'utilise un getter? Je n'ai qu'un attribut dans la classe de test pour les userservice, pas pour les 4 objets individuels.
Vous pouvez essayer d'appeler SetDirty (true) dans votre méthode de test pour recharger le contexte de printemps.
Je n'ai jamais utilisé Mockito, mais Spring-haricots sont des singletons par défaut - ils ne seraient donc pas recréés à moins que vous appeliez Si vous n'en avez pas besoin de singletons, vous pouvez définir leur champ d'application sur Actualiser () sur le conteneur à ressort.
prototype qui créerait de nouvelles instances de haricots sur chaque injection ...
Pour des tests de l'unité et d'intégration clairement distincts (sauter sur le débat de ce que chaque catégorie signifie) - vous pouvez tester votre service de deux manières:
Ma suggestion est de ne pas mélanger le printemps et se moque si vous pouvez l'aider - gardez Mockito pour les tests d'unité (ce dont vous avez besoin à l'aide de celui-ci) et utilisez des tests d'intégration qui recouvrent tout le contexte de printemps pour tester d'autres choses - Préoccupations de persistance, transactions, etc.
Vous n'avez pas besoin de printemps pour se moquer des collaborateurs d'une classe et faire des tests d'interaction simples avec Mockito.
"Ma suggestion n'est pas de mélanger le printemps et se moque si vous pouvez l'aider" exactement. Injectez vos simulacres manuellement si vous avez des setters ou utilisez la méthode réflection de Springs () . Pas besoin de déclencher un contexte de printemps si vos services changent pour chaque test
Vos conseils m'ont aidé à éclaircir certaines choses. Je faisais abuser des mots "test d'intégration" pendant que je voulais vraiment faire un test d'interaction. J'ai choisi à l'origine de ne pas utiliser le printemps pour l'injection de mes simulacres, donc je revient à ce code maintenant, en utilisant uniquement le ressort des tests d'intégration réels. Merci!
Vous réutilisez votre contexte, afin d'avoir des tests indépendants les uns des autres, vous devez probablement actualiser votre contexte après chaque test pour réinitialiser tout.
Je suppose que vous utilisez Junit 4.5+. Ce serait similaire avec d'autres cadres de test. Vous pouvez mettre le Quoi qu'il en soit, je ne pense pas que vous devriez utiliser des moqueurs / espions dans des tests d'intégration: dans des tests unitaires, utilisez des simulacres (si vous le souhaitez) et injecter manuellement. Ici, vous voulez vérifier le comportement de votre haricot testé comme une unité, de sorte que vous l'isolez du reste en utilisant des simulacres. Cela présente également l'avantage que Junit isole vos tests en utilisant une autre instance de la classe d'essai pour chaque test, de sorte que si vous n'utilisez pas Dans les tests d'intégration, utilisez des haricots réels et laissez le ressort injecter. Ici, le but est de vérifier que les haricots interagissent bien entre eux / avec l'environnement (base de données, réseau, ...) que vous faites pas vouloir isoler les haricots ici, vous ne devez donc pas utiliser de moqueurs. < / p>
voir @dirtiescontext au niveau de la méthode si les méthodes nécessitant "la fixation" sont peu nombreuses, mais si vous utilisez le printemps. Meilleure option est de le faire après chaque test.
statique ou d'autres pratiques de test-hospitalier tout simplement fonctionner.
Merci pour l'exemple de code. Comme j'ai commenté la réponse d'Eugen, j'ai mélangé les deux types de tests. C'est ce que j'utiliserai dans mes tests d'intégration réels :)
Merci beaucoup. Ceci peut également être appliqué sur Testng-testclasses qui s'étendent abstractasngspringContextTestStsts .
After_each_Test_Method, génial. Cela a vraiment aidé avec les nouveaux objets de page pour chacun de mes tests.
Avez-vous de multiples méthodes de test, ou juste que vous avez collé?
J'ai quatre méthodes d'essai (1 dont j'ai collé). Je reçois trois tests échoués disant que j'ai appelé les méthodes que j'essayes de tester respectivement 2, 3 et 4 fois.