Discussion :

[rozwel]

Je suis en train de développer une application web avec Hibernate, Spring et Struts. J'aimerais pouvoir tester les couches data et business avant d'implémenter la couche présentation.
J'ai donc essayé d'écrire des tests unitaires JUnit pour mes services Spring mais je n'arrive pas à mettre en place la structure et à démarrer Spring. L'idéal serait même de pouvoir tester les services sans avoir à démarrer de base de données (en utilisant une base en mémoire par exemple).

J'ai cherché des tutoriels là-dessus, mais je n'ai rien trouvé.
Quelqu'un aurait des exemples ou des docs dispos ?

Merci d'avance.

[zekey]

Comment ca tu n'arrive pas à demmarrer spring ?
Il te renvoi une exception ?

[rozwel]

Non. Effectivement j'aurais du être plus précis : en fait je ne sais pas comment faire. Ca peut paraître étonnant vu que je développe avec, mais en fait, l'essentiel des fichiers utiles à Spring est généré par AndroMDA à partir de mon modèle UML. Donc dans l'application Web je n'ai pas à me soucier de ce qu'il faut faire pour démarrer Spring, c'est généré tout seul. Mais AndroMDA ne génère pas encore les tests unitaires, je dois donc les écrire à la main, et c'est là que ça coince.

En d'autres termes, j'ai mon fichier de configuration de Spring, j'ai toutes mes classes d'entités hibernate et de services Spring : la question est de savoir comment utiliser tout ça dans un contexte de tests unitaires exécutés souvent, automatiquement et avec un environnement minimal (pas de base de données démarrée notamment).

[dlemoing]

Il faut à un moment donné que tu charges tes fichiers pour créer un applicationContext.
Tu peux également regarder les classes de Spring pour les tests unitaires (classes avec gestion des transactions et rollback automatique).

[zekey]

En fait tu n'as pas grand chose à faire lorsque tu fait un truc du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ISecurityDao bean = (ISecurityDao) (new XmlBeanFactory(new ClassPathResource(SPRING_CONFIG_FILE))).getBean(SECURITY_DAO_BEAN);

Il va lui même instancier la class ou la recupérer de son pool

(Tu utilises bien spring pour abstraire les couches n'est ce pas ?)

[Alwin]

Tu as, dans Spring, un package test avec quelques petites choses sympatoches pour JUnit et les mock-objects.

Tu doit avant tout ajouter le jar spring-mock.jar qui n'est pas inclus dans le spring.jar (jar complet)

Ensuite, tu as la classe AbstractTransactionalDataSourceSpringContextTests qui, comme son nom l'indique, est abstraite.
Tu doit simplement implémenter la méthode getConfigLocations, exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
protected String[] getConfigLocations() {
  return new String[] {
    "datasourceContext.xml",
    "persistanceContext.xml"
  };
}

Tes fichiers de config doivent être dans le classpath.

Ihth, Valère

[rozwel]

Et voilà, la réponse que je cherchais est tombée sous forme d'un nouvel article dans la section Java qui illustre exactement mon problème et donne la réponse de façon on ne peut plus clair. En fait ce qui me manquait, c'était cette méthode setUp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
protected void setUp() throws Exception {
super.setUp();
// Load Application context.
System.out.println("#JUNIT## SETUP");
bf = new XmlBeanFactory(new ClassPathResource("applicationContext.xml"));
System.out.println("#JUNIT## Init du contexte de l'application.");
toDoService = (ToDoServiceImpl) bf.getBean("toDoServiceTarget");
System.out.println("#JUNIT## Get a reference on singleton toDoService");
todo = new ToDo();
todo.setBody("#JUNIT## UNIT TEST BODY");
todo.setTitle("#JUNIT## TITLE UNIT TEST");
}

Bon alors maintenant j'ai pas encore testé en déploiement mais en tout cas, ça devrait me débloquer.

En attendant merci à vous pour vos réponses.