Junit 4 avec Spring Mvc – Tester les controllers

Lors du développement des applications, le test est la partie plus importante. un test bien organisé permet d’avoir un code correct, qui fonctionne parfaitement. Il y a différents types de test. Dans cet article, je vais introduire le test unitaire des applications basées sur Spring Mvc.

On va commencer par une application plus simple, dans laquelle on apprend comment introduire la configuration des tests unitaires pour une application Spring Mvc.

J’ai utilisé pour ce tutoriel l’IDE Eclipse ainsi que Maven (une autre façon pour développer) pour gérer la dépendances entre les jars.

• Les dépendances  du pom.xml :

• Le hiérarchie du projet :

Jusqu’à maintenant, je n’ai pas encore réalisé un tutoriel qui explique comment créer un projet Maven & Spring Mvc en eclipse, mais le prochain abordera ce thème.

Notre objectif est de tester les méthodes du contrôleur HomeController.java,  le code est :

Comme vous remarquez, il n’y a qu’une seule méthode qui répondra à la requête – /index.html . on testera dans ce cas le statut de la requête ainsi que la vérification du nom de la vue.

Pour le test, on ne contentera pas à la configuration XML pour gérer la partie UrlResolver puisqu’on va utiliser l’approche de configuration programmatique (configuration en tant qu’un programme).

la classe de configuration :

BaseConfigTest.java

Toute la configuration au dessus a sa correspondante au format XML (si vous vous souvenez de la balise ComponentScan bien sur ! ).

Faites bien attention au reste, puisque c’est la ou on trouve pas mal de problèmes :

let’s read the test class :

test class.java

la classe est annotée avec @RunWith fait appel au Spring TestContextManager, permet de initialiser le contexte de l’application pour les tests en utilisant soit le fichier indiqué dans l’annotation @ContextConfiguration, soit la classe indiquée (notre cas 😀 ).

Vous voyez qu’on a utilisé l’injection de dépendance dans cette classe afin d’instancier indépendamment le contexte de l’application grâce à l’annotation @ContextConfiguration et @WebAppConfiguration.

test class.java

pour le premier test, on fait appel à la page d’accueil /index.html. On attends un statut OK ==> 200, ça veut dire que le résultat est celui ce qu’on attend. puis on teste si le nom de la vue qu’on attend est celui envoyé par l’application.

Pour le deuxième test, on appelle la racine du projet (il n’y a pas le mapping pour la racine), on attend plutôt un résultat négatif.

la méthode print() permet d’afficher les paramètres de la requête/réponse.

Pour toutes ces opérations, on utilise un objet mock. MockMvc est un faut objet d’infrastructure Spring ou se déroule le traitement.  Si vous ne connaissez pas les objets mock, Je vous donne un exemple simple. Dans les tests, on utilise les objets mock pour simuler un objet qu’on aura besoin pour effectuer des tests. Par exemple, on utilise un faut d’objet pour simuler l’accès à la base de données et d’avoir récupéré les enregistrements qu’on les ajoute manuellement à l’objet.

Vous remarquez que la syntaxe d’écriture des tests est changé par rapport aux normes. En fait, c’est l’API du test qui nous permet de développer selon cette syntaxe.

Mais avant tout, il faut ajouter ces imports statiquement  :

import pour code réduit

En réalité, on doit développer de cette façon :

test class.java

Le résultat est le suivant :

test_result

Si vous aurez une exception du genre : classDefNotFound … javax:servlet…., n’oubliez d’ajouter le jar javaee.jar.