MÉTHODOLOGIE POUR LES TESTS UNITAIRES
ulm950
Messages postés
4
Date d'inscription
vendredi 15 septembre 2006
Statut
Membre
Dernière intervention
20 mai 2012
-
20 mai 2012 à 11:56
saws Messages postés 3 Date d'inscription vendredi 11 juillet 2008 Statut Membre Dernière intervention 21 mai 2012 - 21 mai 2012 à 13:21
saws Messages postés 3 Date d'inscription vendredi 11 juillet 2008 Statut Membre Dernière intervention 21 mai 2012 - 21 mai 2012 à 13:21
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/54306-methodologie-pour-les-tests-unitaires
https://codes-sources.commentcamarche.net/source/54306-methodologie-pour-les-tests-unitaires
21 mai 2012 à 13:21
1. couche model ou domain :
domain.Client
domain.Fournisseur
2. couche DAO :
dao.ClientDao
dao.FournisseurDao
dao.GenericDAO
idao.IClientDao
idao.IFournisseurDao
3. couche Service
service.ClientService
service.FournisseurService
iservice.IClientService
iservice.IFournisseurService
4. couche présentation (JSF, Struts,...)
ipresentation.ControleurX
C'est souvent l'architecture que j'utilise avec Spring qui lie les différentes couches. Ainsi, la couche métier fait appel à la couche DAO.
Je teste alors la couche DAO sur HSQL avec Junit
et la couche métier en utilisant des objets mock sur la couche DAO via mockito et Junit.
Pour moi toutes les couches doivent être testée indépendamment les unes des autres avec Junit. Et ce afin de permettre à plusieurs développeurs de travailler sur un projet en parallèle.
21 mai 2012 à 12:27
1. la couche model ou domain contient les pojos suivants :
com.model.Client
com.model.Fournisseur
2. la couche DAO contient les classes suivants :
com.dao.impl.ClientDAO (contient les opérations de persistance suivant l’implémentation choisie : hibernate, eclipselink, toplink,... )
com.dao.impl.FournisseurDAO
com.dao.IClientDAO
com.dao.IFournisseurDAO
com.dao.AbstractDAO (une classe DAO générique).
3. la couche métier contient la logique métier :
com.service.ClientService
come.service.FournisseurService
4. la couche présentation (JSF, Struts,...) ne sera pas traitée dans cet exemple.
Alors pour les tests :
les dépendances sont réalisés via Spring qui lie la couche présentation à la couche métier et lie la couche métier à la couche DAO.
Je teste la couche DAO en utilisant junit,
pour la couche service qui fait appel à la couche DAO, j'utilise junit et mockito.
Merci.
21 mai 2012 à 11:39
J'utilise généralement le pattern MVC qui permet de découper sont application en trois couches : modèle, vue et contrôleur.
On ne fait dans ce cas pas appel aux classes DAO depuis les autres classes métier mais, l'appel est réalisé dans les classes du package contrôleur ou dans un service approprié.
Même si tu n'utilises pas ce design pattern, je te déconseil vraiment de faire appel à tes classes DAO dans les autres classes métier, sinon, tu ne pourras pas tester grand chose ou il va falloir faire pas mal de mock sur les classes DAO ce qui est assez pénible.
DBUnit je dirais que c'est plus du coté test unitaire pour les classes DAO mais je n'en suis pas certain. Je n'utilise généralement pas DBUnit que je trouve assez lourd à gérer et qui n'apporte pas grand chose finalement, on se passe d'une base de données mais on a un fichier XML à gérer et ce n'est pas un cadeau. Je préfère utiliser une base de données de test.
Pour la partie 4, c'est juste pour dire qu'en général, les appels à la base de données sont effectués dans des couches de l'application qui ne sont pas testées de façon unitaire. Dans ce cas, on n'a pas besoin de les mocker.
21 mai 2012 à 11:24
Merci pour cette contribution. C'est très intéressant.
Je suis débutant, je n'ai pas compris la partie 4. Les classes d'accès à la base de données.
DBUnit c'est pas pour les tests d'intégration ?
Pourquoi peut on pas appeler une classe DAO directement depuis une classe métier ? C'est quoi les classes de contrôle ? Vous vous basez sur un design pattern particulier ?
J'utilise Spring et pour mes tests, j'emploie Junit et mockito pour tester les couches données et métier. Tout ça sur un serveur Jetty et avec une base de données mémoire HSQL!!!!
Merci de m'apporter plus d’éclaircissements ?
20 mai 2012 à 11:56
Quand aux tests l'injection de dépendance permet de les placer hors package metier (spring), et pour les mock plusieurs framework permettent de les générer (easymock).