Lors de l’intégration des tests unitaires Selenium avec Hudson sur un environnement graphique Linux, j’ai été confronté à l’exception « Selenium – Could not start Selenium session : Failed to start new browser session : Error while launching browser » qui empêchait Selenium Remote Control (RC) d’ouvrir une instance du navigateur Firefox pour le jeu des tests.

La trace de l’exception est la suivante :

java.lang.RuntimeException: Could not start Selenium session: Failed to start new browser session: Error while launching browser
	at com.thoughtworks.selenium.DefaultSelenium.start(DefaultSelenium.java:89)
	at com.mycompany.selenese.util.HomePageTest.setUp(BaseTestCase.java:39)
	at junit.framework.TestCase.runBare(TestCase.java:125)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
(30 more lines...)

En fouillant un peu, j’ai constaté que cette exception est dûe principalement à une mauvaise configuration du profil Firefox utilisé pour le jeu des tests. Il est cependant possible de la résoudre en positionnant la variable browser avec la valeur « *firefox » suivie d’un espace et du chemin absolu du bin Firefox sur le système cible (firefox.exe sous windows et firefox-bin sous linux).

Lire la suite de cet article »

Une question récurrente pour les équipes qui commencent à industrialiser leur build avec du Maven et qui utilisent de manière intensive JUnit. Au bout d’un moment, les tests d’intégrations ralentissent de manière conséquente le build et parfois découragent les développeurs à cause de leurs pré-requis plus importants que les tests unitaires.
Comment les séparer des tests unitaires et comment éviter qu’ils soient lancés à chaque build Maven?

Lire la suite de cet article »

Parmi les tâches incontournables de la vie d’un développeur, il y a l’écriture des tests unitaires. De nombreux outils tentent de nous faciliter la vie sur ce point. Aujourd’hui, je vais vous parler de JTestR, un framework de tests unitaires qui apporte la puissance et la rapidité d’écriture du scripting Ruby pour tester des applications Java. Lancé par Ola Bini, un contributeur incontournable du projet JRuby, JTestR est directement intégrable avec Ant, Buildr et Maven 2. Ce projet n’est pas encore très répandu, mais il apporte des avantages qui méritent d’être étudiés.

Lire la suite de cet article »

Les tests unitaires sont largement répandus et leur utilisation est facilitée grâce à des outils matures tels que JUnit, Unitils, ou les apis de Mocking. Au contraire, la pratique des tests fonctionnels reste encore délicate. Même si des outils comme Selenium, Fitnesse, ou HttpUnit facilitent la création de tests fonctionnels, le problème majeur reste d’automatiser l’exécution des tests, qui sont fortement liés à l’environnement d’exécution de l’application (base de données, serveur, dossiers de travail, fichiers de configuration, etc.). Je vais vous présenter une manière de réaliser l’automatisation, il existe des solutions alternatives utilisant DbUnit et Cargo, dont je vous ferai part.

Ainsi, l’automatisation des tests fonctionnels doit permettre de :

1. Initialiser la base de données avec un jeu de données.
2. Construire le WAR de l’application.
3. Démarrer le serveur web et déployer l’application.
4. Exécuter les tests fonctionnels.
5. Arrêter le serveur web.

Pour réaliser cela, cet article s’appuie sur l’outil Ant, qui reste encore répandu malgré Maven. Le passage de l’un à l’autre peut s’effectuer sans avoir à tout re-développer, car j’ai implémenté principalement du code Java réutilisable.
Cet article se concentre sur l’automatisation au niveau de la base de données et du serveur web. Ainsi, la construction du WAR et l’exécution des tests fonctionnels ne seront pas abordés.

Lire la suite de cet article »

Dans un projet J2EE, il est toujours utile de pouvoir déployer son application sur un serveur et plus encore pour faire de l’intégration en continu avec des tests fonctionnels. La plupart du temps, on utilise un serveur dédié pour les tests et les outils livrés avec pour gérer les déploiements.

Cargo utilise les outils de chaque serveur et livre une interface unifiée pour administrer les serveurs J2EE. En bref, Cargo permet d’installer, de configurer, de lancer et d’arrêter des serveurs dans une approche multi-conteneurs. De plus, on peut enfin l’utiliser à travers plusieurs outils, puisqu’il fournit des extensions pour Netbeans, Ant, IntelliJ, Maven 1 et 2, et bien sûr une API java.

Dans cet article, nous présenterons d’abord Cargo et son fonctionnement, puis un exemple concret d’intégration continue dans un projet Maven avec Cargo et Selenium.

Lire la suite de cet article »

Les outils d’analyse statique du code permettent de détecter automatiquement certaines anomalies d’une application. Plus les anomalies sont détectées rapidement moins leur coût de correction est élevé. Certains estiment que si la correction d’un bug coûte ’1′ durant la phase de développement, elle coûtera ’10′ en phase de recette et ’100′ en production. Les objectifs de ces outils sont nobles : détecter un maximum d’anomalies durant la phase de développement et réduire le nombre de bugs tout en rendant le code plus performant et homogène. Il s’agit d’un des outils de QA dont disposent les développeurs afin de garantir la qualité de leur code. Les plus connus et utilisés dans le monde Java sont Checkstyle, PMD et FindBugs. Checkstyle permet, par exemple, de lever des alertes en cas d’utilisation de valeurs _en dur_ dans le code alors qu’une constante serait la bienvenue. PMD détecte entre autres la présence de blocs catch vides … et Findbugs détecte l’utilisation de la méthode equals sur des objets n’ayant pas le même type … David Hovemeyer et William Pugh, les créateurs de FindBugs, ont décidé de ne pas contrôler les problèmes de style ou de format et de se limiter à la recherche de véritables bugs.

Le principal danger de ce type d’outil est de noyer le développeur dans une foule d’informations ne correspondant pas à son besoin. Les règles étant en général prédéfinies par ces outils, elles ne peuvent pas toutes s’appliquer à tous les contextes. Pour éviter cette mauvaise analyse et la levée de false positives, il est en général possible de configurer les outils pour activer, désactiver ou modifier ces règles à la demande.

Par ailleurs, aussi conséquent soit-il, le nombre de règles proposé reste limité. Il serait pourtant pratique d’ajouter au besoin nos propres règles afin de profiter aux mieux de ces outils. C’est ce qu’on nous allons faire dans la suite du billet. Comme l’ajout de règle est relativement bien documenté pour checkstyle et PMD, nous nous intéresserons ici à la création d’un nouveau détecteur FindBugs.

Lire la suite de cet article »