Tests unitaires vs tests d'intégration avec Spring

Question

Je suis en train de travailler sur un Spring MVC projet, et j'ai des tests unitaires pour l'ensemble des divers éléments dans l'arbre source.

Par exemple, si j'ai un contrôleur HomeController, qui doit avoir un LoginService injecté dans, alors dans mon unité de test HomeControllerTest j'ai simplement créer une instance de l'objet en tant normal (en dehors de Printemps) et injecter de la propriété:

protected void setUp() throws Exception {
    super.setUp();
    //...
    controller = new HomeController();
    controller.setLoginService( new SimpleLoginService() );
    //...
}

Cela fonctionne très bien pour tester chaque composant comme une unité isolée - sauf que maintenant que j'ai quelques dizaines de classes dans le projet, après l'écriture d'une classe et de l'écriture avec succès un test unitaire pour elle, j'oublie de mettre à jour mon Spring MVC fichier de contexte qui fait tout le câblage dans l'application déployée. Je trouve que j'ai oublié de mettre à jour le fichier de contexte quand j'déployer le projet sur Tomcat et trouver un tas de NullPointers de non-câblé haricots.

Donc, voici mes questions:

1. C'est mon premier projet pour le Printemps - est-il normal de créer des tests unitaires pour l'individu, les haricots, comme je l'ai fait, et ensuite de créer une deuxième série de tests (tests d'intégration) pour tester que tout fonctionne comme prévu avec le contexte de l'application? Est-il une meilleure pratique établie pour cela?

2. En outre, comment voulez-vous séparer les tests unitaires à partir des tests d'intégration? J'ai tout le code source en src, les tests unitaires en test - devrait-il y avoir un 2ème test de dossier ( test-integration) pour l'intégration des cas de test?

Comme c'est mon premier projet pour le Printemps, je suis curieux de voir comment les autres vont habituellement à propos de faire ce genre de chose - et plutôt que de ré-inventer la roue, je préfère demander au reste de la communauté.

Answer 1

Je ne peux pas parler pour être une bonne pratique, mais voici ce que j'ai fait dans le passé.

Tests unitaires:

• Créer des tests unitaires pour les non-trivial haricots (c'est à dire, la plupart de vos Printemps liées haricots)
• Mocker pour injecté services lorsque c'est possible (c'est à dire, la plupart, si pas tout le temps).
• Utiliser une convention de nommage pour ces tests dans le projet test répertoire. À l'aide de Test ou TestCase comme un préfixe ou un suffixe à celui de la classe semble être largement pratiqué.

Les Tests D'Intégration:

• Créer un AbstractIntegrationTestCase qui met en place un Spring WebApplicationContext pour une utilisation dans intetgration test clases.
• Utiliser une convention de nommage pour les tests d'intégration dans l' test répertoire. J'ai utilisé IntTest ou IntegrationTest comme un préfixe ou un suffixe pour ces tests.

Mettre en place trois Ant test objectifs:

1. test-tout (ou ce que vous voulez l'appeler): Exécuter les Tests Unitaires et d'Intégration
2. test: Exécuter les tests Unitaires (simplement parce qu' test semble être l'utilisation la plus courante pour les tests unitaires
3. test d'intégration: exécuter les tests d'intégration.

Comme indiqué, vous pouvez utiliser les conventions de nommage qui font sens pour votre projet.

Comme pour la séparation de l'unité à partir de tests d'intégration dans un répertoire séparé, je ne pense pas que cela importe, tant que les développeurs et leurs outils peuvent trouver et de les exécuter facilement.

Comme un exemple, le dernier projet en Java, j'ai travaillé avec le Printemps utilisé exactement ce qui est décrit ci-dessus, avec les tests d'intégration et tests unitaires vivant dans le même test répertoire. Graal des projets, d'autre part, explicitement unité séparée et test d'intégration sous-répertoires d'un test général de répertoire.

Answer 2

Quelques cas isolés de points:

Oui, c'est une approche commune pour le Printemps de test séparée des tests unitaires et des tests d'intégration où les anciens ne charge pas tout le Printemps contexte.

Pour vos tests unitaires, peut-être envisager de se moquant de s'assurer que vos tests sont concentrés sur un isolé module.

Si vous êtes tests de câblage dans une tonne de dépendances alors qu'ils ne sont pas vraiment des tests unitaires. Ils sont les tests d'intégration où vous êtes le câblage de dépendances à l'aide de nouvelles plutôt que de l'injection de dépendance. Un gaspillage de temps et d'efforts redondants lorsque votre application en production utilise le Printemps!

Base de tests d'intégration pour apporter votre Printemps contextes sont utiles.

Le @annotation requise peut vous aider à vous assurer d'attraper les dépendances nécessaires dans votre Ressort de câblage.

Peut-être Maven qui vous donnera explicite phases de lier votre appareil et les tests d'intégration sur. Maven est très largement utilisé dans le Ressort de la communauté.

Answer 3

Beaucoup de la fastidieuse double-tenue de la comptabilité avec le printemps s'en va, si vous aussi passer à un niveau purement annoté régime, où vous annoter tous vos haricots avec @Composant, @Contrôleur, @Service et @Référentiel. Juste ajouter @Autocâblés pour les attributs que vous avez besoin pour obtenir injecté.

Voir la section 3.11 du printemps manuel de référence. http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config

Sur une note connexe, nous avons été à l'aide de la division de l'Unité/Integratrion tests KenG décrire. Dans mon dernier régime que nous avons également introduit une troisième "classe" des tests", ComponentTests". Ces exécuté avec plein printemps de câblage, mais avec filaire stub implémentations (à l'aide de component-scan des filtres et des annotations au printemps).

La raison derrière cela est parce que pour certains le "service" de la couche, vous vous retrouvez avec une effroyable quantité de main-codé câblage logique manuellement le fil de la fève, et parfois des quantités ridicules de la maquette des objets. 100 lignes de câblage pour 5 lignes de test n'est pas rare. Les tests d'éléments de remédier à ce problème.

Answer 4

Utilisez l'interface InitializingBean (implémente une méthode "afterPropertiesSet") ou spécifiez une méthode init pour vos beans. InitializingBean est généralement plus facile car vous n'avez pas besoin de vous rappeler d'ajouter la méthode init à vos beans.

Utilisez afterPropertiesSet pour vous assurer que tout est injecté comme non nul, s'il est nul, lève une exception.

Answer 5

Lorsque j'ai créé les tests d'intégration pour les applications web, je les ai mis dans un répertoire séparé. Ils sont construits en utilisant jUnit ou TestNG et d'interagir avec le système en cours de test à l'aide de quelque chose comme le Sélénium qui frappe les pages web comme si elles étaient des utilisateurs. Le cycle aller comme ceci: compilation, exécution de tests unitaires, de construire l'application web, la déployer sur un serveur en cours d'exécution, exécuter les tests, annulez le déploiement de l'application, et de faire rapport des résultats. L'idée est de tester l'ensemble du système.