Auteur

Alexandre Lacroux

Fil des billets

Par Alexandre Lacroux, le 27 avril 2012
Catégorie : Java J2EE

Subtilité HibernateTemplate : différence entre get et load

Dans le cadre de la recherche d'un objet en base de données par son identifiant, Hibernate fournit plusieurs méthodes via la classe HibernateTemplate. Parmi elles, on trouve la méthode load et la méthode get. Mais attention, malgré les apparences, ces deux méthodes de récupération d'objet sont différentes. Voici leur javadoc respective :

Object get(Class entityClass, Serializable id) throws DataAccessException

Return the persistent instance of the given entity class with the given identifier, or null if not found.

Object load(Class entityClass, Serializable id) throws DataAccessException

Return the persistent instance of the given entity class with the given identifier, throwing an exception if not found.

La principale différence entre ces deux méthodes est ce qu'elles renvoient dans le cas où l'objet correspondant à la classe et à l'identifiant donnés en paramètres n'existe pas : la méthode get renvoie null si elle ne trouve pas de résultat, alors que la méthode load renvoie un objet non null qui est un proxy. Ce proxy n'est d'ailleurs pas exploitable en mode debug.

Par Alexandre Lacroux, le 15 novembre 2011

Tests fonctionnels en intégration continue

Introduction

Tout au long de ce blog, je vais vous présenter une manière de jouer des tests fonctionnels en intégration continue. L’avantage de la méthode décrite ici est qu’elle est totalement décorélée du langage de programmation de l’application à tester. En effet, les tests fonctionnels ne concerne que la couche web de l’application : ils sont directement enregistrés et joués sur le navigateur.

Jouer des tests fonctionnels en intégration continue permet d’avoir une vision globale, continue et en temps réel de l’état de fonctionnement de l’application web.

Outils

Selenium

L’outil que nous allons utilisé pour enregistrer les tests fonctionnels est Selenium (http://seleniumhq.org/). Il permet d’enregistrer les actions de l’utilisateur sur l’application web à tester (cliques, saisies de textes, navigations etc) et de les rejouer à la demande, sur la même adresse où sur une adresse différente (pour tester plusieurs environnements avec les mêmes tests). Par défaut, les tests sont enregistrés au format xml, ce qui permet de les ré-ouvrir et de les modifier directement dans Selenium IDE. Le principal avantage de Selenium, qui est par la même occasion la raison pour laquelle nous allons l’utiliser, est qu’il permet ensuite d’exporter les cas de tests sous différents formats : Ruby, Groovy, Perl, PHP, Python et C#, sans oublier JUnit 3 et JUnit 4.

Maven

Le but de ce blog n’est pas d’expliquer le fonctionnement de ce framework que l’on ne présente plus. Précisons tout de même qu’il permet de jouer tous les tests d’un projet grâce à une simple ligne de commande.

Hudson & SVN

Hudson est un serveur d’intégration continue, qui permet de construire les projets qui lui sont confiés. Concrètement, dans la cas d’un projet sous maven puisque c’est de ça qu’il s’agit, il peut lancer une commande maven à l’aide de “job” que l’utilisateur doit paramétrer. Il peut, entre autres, régler la fréquence à laquelle les jobs sont exécutés.

Il est possible de relié ce serveur d’intégration continue à un serveur de gestion de version, dans notre cas SVN. A chaque modification des sources sur le serveur SVN, Hudson récupère les sources impactées pour être en permanence à jour.

Mise en place

Etape 1 : Enregistrement des tests avec Selenium

Nous allons utiliser 2 composants de la suite Selenium :

  • Selenium IDE, qui est un plugin Firefox qui permet d’enregistrer les tests.
  • Selenium Remote Control, qui contient le serveur Selenium chargé de jouer les tests à distance.

Ces deux composants sont disponibles gratuitement à l’adresse suivante : http://seleniumhq.org/download/

Grâce au premier, on enregistre donc nos tests fonctionnels directement sur l’application web. Ce composant permet d’enregistrer les actions de l’utilisateur, tels que les cliques, les saisis de textes ou les navigations. Une fois le test enregistré au format xml par le plugin, choisissons dans le menu de l’exporter au format JUnit 4.

Le second composant (Selenium RC) servira à jouer ce test lorsqu’il sera lancé en tant que test unitaire. Pour lancer le serveur Selenium situé dans l’archive téléchargée, la commande est la suivante :

java -jar selenium-server

Le serveur Selenium est lancé et prêt à recevoir des tests à jouer sous firefox.

Etape 2 : Création du projet maven

Pour créer un projet maven vide qui contiendra uniquement les tests, nous allons utiliser le plugin archetype. Il suffit de se positionner dans le workspace est d’exécuter la ligne suivante :

mvn archetype:generate -DgroupId=com.javaworld.projet -DartifactId=projet-selenium -Dversion=1.0

Une fois le projet de tests créé, importons les tests et ajoutons la dépendance suivante à notre pom.xml :

 <dependency>
<groupId>org.seleniumhq.selenium.client-drivers</groupId>
<artifactId>selenium-java-client-driver</artifactId>
<version>1.0.1</version>
</dependency>

A noter que dans le test JUnit exporté par Selenium IDE, dans la méthode setUp() exécuté avant la méthode de test, le constructeur utilisé pour instancier l’objet “selenium” prend en paramètres : DefaultSelenium(String serverHost, int serverPort, String browserStartCommand, String browserURL)

  • serverHost : l’adresse du serveur Selenium RC (localhost s’il tourne en local, l’adresse d’une VM dédiée dans l’idéal)
  • serverPort : le port d’écoute du serveur Selenium RC (4444 par défaut)
  • browserStartCommand : la commande de lancement du navigateur à utiliser pour jouer les test (*firefox par exemple)
  • browserUrl : l’adresse de l’application à tester

Maintenant, il faut déposer les sources sur le serveur SVN pour que Hudson puisse les récupérer.

Etape 3 : Création du job hudson

Nous allons maintenant créer un job Hudson qui sera en charge de jouer nos tests périodiquement à l’aide d’une commande maven.

Lors de la création d’un job, de nombreux réglages plus ou moins utiles sont proposés. Dans notre cas, il suffit de renseigner :

  • Gestion de code source : sélectionner “Subversion” et indiquer l’adresse du trunk du projet sur le serveur SVN dans la partie “URL du repository”;
  • Ce qui déclenche le build : si on ne touche rien, le build doit être déclenché manuellement par un utilisateur. Sinon, nous pouvons charger Hudson de le faire pour nous à des fréquences paramétrables (“Construire périodiquement”);
  • Buid : sélectionner “Invoquer des cibles maven de haut niveau”. La cible maven est la suivante : “clean test” (pour “nettoyer” le projet puis jouer l’intégralité des tests);
  • Actions à la suite du build : dans notre cas, il peut être intéressant de renseigner “Publier le rapport des résultats des tests JUnit”.

On peut maintenant sauvegarder le job, puis le lancer.

Résultat

Lorsque le job est lancé par le serveur Hudson, les tests sont lancés et donc exécutés par le serveur selenium sur l’application web disponible sur la plate-forme cible. Bien sûr, pour que le suivi de l’exécution des tests dans le temps ait un intérêt, il faut déployer régulièrement l’application en cours de développement sur la plate-forme cible. Il existe pour cela des plugins maven de déploiement automatique.

Conclusion

Grâce à cette solution, nous sommes capables de jouer des tests fonctionnels en intégration continue. L’ensemble des outils utilisés sont gratuits et open source, et la mise en place de la solution est rapide.