GXT (grâce à GWT) permet de créer des applications web riches, dont l’ergonomie est assez proche d’une application lourde. Nous avons déjà eu l’occasion de publier des articles à ce sujet sur ce blog. Il est assez simple de faire des tests unitaires sur des services dans les couches basses d’une application. Et encore, dès qu’il y a une base de données en jeu, ça se complique (et c’est d’ailleurs très souvent le cas). Mais qu’en est-il des interfaces graphiques ? Evidemment, certains éléments graphiques peuvent être testés via des tests unitaires, mais comment s’assurer que l’interface, dans son ensemble, répond aux besoins ?

C’est là qu’intervient Selenium. Selenium est un jeu d’outils qui permettent d’automatiser les tests d’interface graphique, en pilotant un navigateur via du code (ce code, c’est le testcase). Par exemple, on va pouvoir demander le chargement d’une page, effectuer un clic sur un lien bien précis, vérifier que la page contient un texte, … Une session complète sera dédiée à Selenium au DeveloperForum 5, le 8 octobre 2009 à Strasbourg.

Mais avant de pouvoir tester nos interfaces, il faut mettre en place Selenium. Voici comment faire fonctionner Selenium dans un projet GWT dans Eclipse sur Mac OS X Snow Leopard (10.6).

Comment ça marche ?

Il faut deux éléments pour faire fonctionner le tout :

• Selenium IDE est une extension Firefox qui permet d’enregistrer les actions réalisées dans la fenêtre de Firefox et d’ainsi produire le code du testcase (dans le langage de votre choix – dans notre cas, ce sera Java).
• Selenium RC (Remote Control) est un serveur capable de piloter un navigateur et pouvant recevoir des commandes via le réseau, déclenchées par le testcase.

Mise en place

Utilisez Firefox pour télécharger et installer Selenium IDE (extension Firefox) : http://seleniumhq.org/download/
Téléchargez ensuite Selenium RC et décompresser l’archive dans le répertoire de votre choix. Depuis ce répertoire, lancez Selenium RC via la ligne de commande :

java -jar selenium-server-1.0.1/selenium-server.jar

Le serveur se lance et devrait vous afficher les gentillesses suivantes :

10:53:44.369 INFO - Java: Apple Inc. 14.1-b02-90
10:53:44.370 INFO - OS: Mac OS X 10.6.1 i386
10:53:44.379 INFO - v1.0.1 [2696], with Core v@VERSION@ [@REVISION@]
10:53:44.461 INFO - Version Jetty/5.1.x
10:53:44.462 INFO - Started HttpContext[/selenium-server/driver,/selenium-server/driver]
10:53:44.463 INFO - Started HttpContext[/selenium-server,/selenium-server]
10:53:44.463 INFO - Started HttpContext[/,/]
10:53:44.475 INFO - Started SocketListener on 0.0.0.0:4444
10:53:44.475 INFO - Started org.mortbay.jetty.Server@1ff7a1e

Premier test

Dans Firefox, allez sur une page web de votre choix puis, dans le menu Outils, choisissez Selenium IDE. Commencez à surfer sur la page web et regardez Selenium « Big Brother » IDE enregistrer toutes vos actions dans le navigateur… Exactement comme lorsqu’on enregistre un macro dans certains logiciels. Après avoir navigué dans quelques pages, sélectionnez du texte dans la page et faites un clic droit puis sélectionnez l’option verifyTextPresent <le texte que vous avez sélectionné>.

Dans le menu de la fenêtre de Selenium, choisissez Exporter le test sous… puis choisissez Java (JUnit). Enregistrez le fichier avec le nom de votre choix, sans oublier l’extension .java.

Dans Eclipse, dans votre projet GWT/GXT, créez un nouveau dossier de sources nommé test (si ce n’est pas déjà fait). Ajoutez-y le fichier généré par Selenium IDE puis corrigez le nom du package ainsi que le nom de la classe. Corrigez le build path de votre projet en ajoutant le JAR selenium-java-client-driver.jar (que vous trouverez dans l’archive de Selenium que vous avez téléchargée). Clic droit sur la classe dans Eclipse puis Run As > JUnit Test.

Et là, c’est le drame : une erreur se produit lors du lancement de Firefox. Après le passage à Snow Leopard, une incompatibilité de librairie est arrivée. Pour la contourner, il existe une solution qui vaut ce qu’elle vaut (j’adore cette expression qui ne veut rien dire dans l’absolu et qui pourtant veut bien dire… ce qu’elle veut dire !) :

• Quittez Firefox
• Lancer le Terminal puis rendez-vous dans /Applications/Firefox.app/Contents/MacOS.
• Renommez libsqlite3.dylib : mv libsqlite3.dylib _libsqlite3.dylib

Relancez votre testcase et tout devrait rentrer dans l’ordre !

Il existe bien sûr un guide de migration qui permet de passer de GXT 1.x à GXT 2.x, avec plus ou moins de succès. Mais une chose importante a été oubliée dans ce guide. Quand on utilise des listes paginées, le paramètre indiquant la page de données voulue s’appelait auparavant start, il s’appelle désormais offset. C’est comme ça, et ce n’est pas paramétrable.
Faut juste modifier toutes les servlets… à moins que, comme nous, vous n’ayez centralisé ce genre de choses.

Après MashupXFeed et les réseaux sociaux, retournons à un peu de technique : comment gérer le changement de sélection dans une ListView et récupérer la sélection ?

Voilà une réponse possible : ajouter un listener sur le SelectionModel.

// Initialize the ListView and required stuff to load and display it.
ListView<ModelData> listView = new ListView<ModelData>();
listView.setTemplate(getTemplate());
listView.setItemSelector("div.listview-item");
 
// Setup selection Listener.
listView.getSelectionModel().addListener(
   Events.SelectionChange,
   new Listener<SelectionEvent<ModelData>>() {
      public void handleEvent(SelectionEvent<ModelData> se) {
         ModelData selectedModel = se.selection.get(0);
      }
   });

À chaque fois que j’en ai besoin, c’est pareil : je ne me souviens jamais de la manière de tester la « valeur de retour » de MessageBox.confirm(). Alors en l’écrivant ici, peut-être que je finirai par m’en souvenir…

Listener<WindowEvent> handler = new Listener<WindowEvent>() {
    public void handleEvent(WindowEvent be) {
        Dialog dialog = (Dialog) be.component;
        Button btn = dialog.getButtonPressed();
        if (btn.getItemId().equals(Dialog.YES)) {
            // L'utilisateur a confirmé !
        }
    }
};
MessageBox.confirm(
    "Confirmation", "Souhaitez-vous réellement... ?", handler
    );

Je viens de passer un certain temps à me rendre compte que dans la méthode dragCancel() d’un objet DragListener la propriété component de l’objet DragEvent reçu en argument vaut null ! Donc si vous avez besoin de cette information, pensez à la stocker dans votre objet dans la méthode dragStart()…

Version de GXT : 1.2.3

L’utilisation d’un RowLayout dans un conteneur supprime la possibilité d’avoir une barre de défilement pour ce conteneur. En fait, la raison est assez simple : RowLayout calcule la position et la taille précises de chaque enfant, et c’est à chacun de ses enfants de gérer sa barre de défilement, au besoin.

Donc, si vous avez besoin d’une barre de défilement dans un panneau, n’utilisez pas RowLayout : dans la plupart des cas, un FlowLayout peut être préférable. Utiliser un FlowLayout revient à utiliser un RowLayout(Orientation.VERTICAL) avec des contraintes RowData(1, -1) pour chaque enfant (c’est-à-dire : utiliser toute la largeur disponible et laisser chacun des enfants calculer sa propre hauteur).