Bla bla blog

Aller au contenu | Aller au menu | Aller à la recherche

mardi 10 février 2009

Milestone 1 pour Eclipse 4

La fondation Eclipse vient de publier le premier milestone de la version 4 de sa plate-forme. Cette version promet de nombreux changements que vous pouvez découvrir à cette adresse.

La grande nouveauté vient de la définition de la structure des IHM (menu, perspectives, vues, etc...) qui sera désormais faite via EMF (Eclipse Metamodel Framework) et non plus directement en SWT. L'idée étant de tendre vers le RAD (Rapid Application Development) et donc qu'à partir d'une modélisation que tout le code SWT/JFace soit généré. La seconde grande nouveauté vient du support de CSS (Cascading StyleSheet) pour la mise en forme via des styles de la structure précédemment définie.

J'ai hâte de tester davantage ces deux points ainsi que la gestion des modèles de données à associer aux écrans ainsi définis. Nul doute que le projet est intéressant, j'admets tout de même avoir quelques craintes pour les projets RCP existants à migrer vers cette nouvelle mouture de la plate-forme Eclipse. Ces quelques tests à venir seront l'occasion d'un nouveau billet.

lundi 9 février 2009

Exemple : Tester une application avec SWTBot

Suite à la présentation qui a été faite de SWTBot, nous allons présenter dans cette article un exemple de test sur une application développée avec SWT. Nous avons choisi une application de Tchat avec deux tests à réaliser : s'assurer que les composants graphiques sont bien présents et qu'après l'envoi d'un message la zone de saisie est de nouveau vide. Chat swt

Classe de test

Définition

Les classes de tests dans SWTBot doivent hériter de SWTBotTestCase. Cette classe hérite elle-même de la classe TestCase de JUnit, ce qui prouve que SWTBot est une extension du framework JUnit. Cela signifie également que vous aurez la possibilité de redéfinir les méthode setUp() et tearDown() dans vos classes de test.

Démarrage de l'application

Pour plus de facilité, c'est la classe de test qui va démarrer notre application graphique dans un autre thread. Nous allons donc ajouter une partie static qui se chargera du lancement de l'application à tester au chargement de la classe de test.

static {
    startApplicationInAnotherThread();
}
private static void startApplicationInAnotherThread() {
    new Thread(new Runnable() {
        public void run() {
            new ChatView().main(new String[]{});
        }
    }).start();
                
    long endTime = System.currentTimeMillis() + 5000;
    while (System.currentTimeMillis() < endTime) { 
    try {
        Display display = SWTUtils.display();
        if (display != null)
            break;
    } catch (Exception e) { }
    }
}


On voit dans cet exemple que l'application ChatView est démarrée, puis on essaie de récupérer l'objet Display dans un boucle while pour s'assurer que l'application graphique a bien été démarrée avant de commencer l'exécution des tests


Ecriture des tests

Les méthodes de test doivent toutes être nommée testXXX(), Il s'agit d'une convention reprise de JUnit. Puis il s'agit de récupérer des références sur les objets graphiques de l'interface, cette opération se fait via l'attribut bot, qui est hérité de la classe SWTBotTestCase. Enfin les méthodes assertXXX() (comme dans Junit) nous permettrons de tester l'état de nos composants graphiques.
Voici un exemple qui permet de s'assurer que tous les composants graphiques de l'interface sont bien présents et actifs. Notez la manière de récupérer une référence sur l'objet graphique via bot.

public void testPresence() throws Exception{
    assertNotNull(bot.activeShell());
    assertEnabled(bot.text(""));
    assertEnabled(bot.button("Envoi"));
}


Ici un autre exemple qui permet de dérouler un scénario fonctionnel, l'envoi d'un message via l'IHM de tchat, et de s'assurer une fois le message envoyé que la zone de saisie est bien vide.

public void testEnvoi() throws Exception{
    SWTBotText txt = bot.text("");
    txt.setText("Bonjour à tous");
    bot.button("Envoi").click();
    assertEquals("", txt.getText());
}

Exécution du test

Dans Eclipse l'exécution du test sera identique à celle d'un test JUnit, c'est à dire via le menu run... Notez tout de même qu'en mode debug, les méthodes pour récupérer une référence sur un objet graphique ne fonctionnent pas, cela vient probablement de la gestion des threads (ce point reste à élucider). Dernière remarque, si vous écrivez plusieurs classe de tests, il serait bon de les regrouper dans une TestSuite de manière à ne démarrer qu'une seule fois l'application.
Tout le code est en pièce jointe.

samedi 7 février 2009

Tester une application SWT avec SwtBot

Il faut bien le reconnaître peu de frameworks permettent de tester une IHM développée avec SWT, bien entendu il existe des suites de tests proposées sous licences commerciales comme GuiDancer ou Froglogic, mais le moins qu'on puisse dire est que la communauté open source n'est pas très prolifique sur le sujet (en tout cas à ma connaissance). Ayant remarqué le projet SwtBot lors de l'Eclipse Conference 2008, j'ai testé ce framework, ce qui me donne une bonne occasion pour écrire un nouveau billet.

Présentation

SWTBot est un framework de tests fonctionnels pour les interfaces graphiques développées avec SWT/JFace. Il est distribué sous licence Apache à l'adresse suivante http://swtbot.sourceforge.net/index.html, vous pourrez d'ailleurs remarqué que la documentation n'est pas vraiment au niveau sur ce site, d'où l'idée de vous évitez les déboires que j'ai pu rencontrer via ce billet. Au niveau de la philosophie de ce framework, l'approche est semblable à JUnit (notion de TestCase, redéfinition des méthodes setUp() et tearDown(), les méthodes de tests se nomment testXXX) puisqu'il s'appuie sur ce Framework. De nouvelles méthodes assertXXX() viennent enrichir celles spécifiques à JUnit et sont notamment très utiles pour tester l'état des composants graphiques. Enfin les composants graphiques SWT ont également été étendu pour pouvoir faire quelques opérations de base sur ces derniers depuis nos tests, ainsi SWTBotButton sera l'équivalant de l'objet graphique Button.

Installation du framework

Il est possible d'utiliser ce framework de manière autonome, toutefois comme il est livré sous forme de plugin Eclipse, je recommande ce mode d'installation. Attention il vous faudra une version 3.3 (Europa) au minimum. Cette installation se fera via un site distant dont l'url est http://swtbot.sourceforge.net/update-site (le mode opératoire est rappelé dans ce précédent billet). Une fois le plugin installé, il vous faut créer un projet Java dans lequel seront regroupés vos tests (si vous choisissez de mettre vos tests dans le même projet que l'application à tester, créez au moins un package ou un répertoire source distinct pour les tests). Maintenant il vous faut ajouter les librairies suivantes pour que vos tests puissent fonctionner :

  • JUnit
  • SWT (disponible dans les jars d'Eclipse ou en téléchargement sur http://www.eclipse.org/swt)
  • net.sf.swtbot.finder_<version info>.jar (répertoire /plugins d'eclipse)
  • org.eclipse.core.commands_<version info>.jar (répertoire /plugins d'eclipse)
  • org.eclipse.equinox.common_<version info>.jar (répertoire /plugins d'eclipse)
  • org.eclipse.jface_<version info>.jar (répertoire /plugins d'eclipse)
  • org.eclipse.osgi_<version info>.jar (répertoire /plugins d'eclipse)
  • org.eclipse.ui.workbench_<version info>.jar (répertoire /plugins d'eclipse)
  • org.apache.commons.collections_<version info>.jar (répertoire /plugins d'eclipse)
  • org.apache.log4j_<version info>.jar (répertoire /plugins d'eclipse)

Enfin il vous reste à configurer le logger log4J et ses appenders, cette opération peut se faire via un fichier log4j.xml à placer à la racine des packages (vous avez l'exemple fourni par SWTBot en pièce jointe)

Mise en oeuvre des tests

Comme les tests d'application SWT s'appliquent à deux cas pratiques : une application autonome et un plugin Eclipse graphique, je propose de rédiger un billet pour chacun de ces cas pour éviter redondance ou superposition d'informations.

Mon sentiment à chaud

Déjà ce framework a le mérite d'exister, il représente du travail fourni gracieusement, c'est donc toujours bon de le saluer. Je n'ai pas rencontré d'autres frameworks OS répondants aux mêmes exigences, mais peut-être suis-je passé à côté (si vous avez d'autres expériences, je suis preneur et les commentaires sont faits pour ça) Dans leur organisation les tests ne dérouteront pas les développeurs Java habitués des tests unitaires à la JUnit, c'est pour moi également un avantage, d'autant qu'il sera possible de les lancer via une tâche ANT ou de les intégrer dans un build Maven et donc dans une démarche d'intégration continue.

Mes craintes viennent davantage de la difficulté à maintenir de tels tests , surtout sur des IHM complexes... les défaut de SWTBot seront les mêmes que ceux de HttpUnit par exemple. On peut également noter le manque d'outillage pour par exemple enregistrer un séquence d'interactions avec l'IHM, comme lorsqu'on réalise une macro ou pour les suite de tests comme dans un outil comme loadRunner... J'ai également quelques craintes sur la pérennité du projet qui évolue peu depuis 8 mois et sur la faiblesse de la documentation, mais comme indiqué sur le site de SWTBot : Looking for documentation that is not here ? Consider contributing . Alors si vous êtes motivés , à vous de jouer.

mercredi 17 septembre 2008

Installer un plugin pour Eclipse

Eclipse est cet environnement de développement open source (licence EPL) omniprésent qui a l'avantage d'être modulaire. C'est à dire configurable à souhait via l'ajout ou le retrait de plugin. Ce billet fait le point sur ces plugins et surtout leurs modes d'installation.

Où trouver les plugins

Le plugins sont souvent le fait d'initiatives open source et sont par définition éparpillés aux quatre coins du web. D'autres plugins sont sous licence commerciale et sont souvent des adaptation d'outils précédemment commercialisés qui ont été portés sur la plateforme Eclipse et vous les trouverez sur les sites de ces éditeurs. En tout cas l'utilisateur d'Eclipse a du mal à s'y retrouver, c'est pourquoi quelques sites référencent tous ces plugins qu'ils soient sous licence commerciale, open source, graticiel, etc. Parmi ces sites, on peut citer :

Installer un plugin

Une fois le plugin identifier il faut l'installer, pour celà il existe deux modes :

  • installation distante via une url
  • installation après téléchargement

Installation via une URL

Ce mode d'installation est le plus simple à condition que l'éditeur de votre plugin vous fournisse une URL à partir de laquelle Eclipse va pouvoir télécharger le plugin et l'installer automatiquement. Ce mode permet également à Eclipse d'interroger régulièrement pour voir si une nouvelle version du plugin est disponible. Voici les étapes à respecter pour une telle installation :

  1. Menu Help>Software updates>Find and install...
  2. Sélectionner "Search for new features to install"
  3. Cliquer sur le bouton "New Remote Site" et saisir l'URL du site d'installation du plugin ainsi qu'un nom pour l'identifier par la suite siteUpdateEclipse
  4. Laisser vous guider pour la suite de l'installation, Eclipse se charge de télécharger et installer votre plugin

Installation après téléchargement

Vous venez de récupérer un plugin sous forme d'une archive. Après avoir décompresser cette archive, vous allez constater qu'elle contient deux répertoires : /features et /plugins. Ces deux répertoires sont également présent dans la structure de répertoires d'Eclipse /eclipse/features et /eclipse/plugins. L'installation d'une telle archive consiste donc à la décompresser dans la structure de répertoires d'Eclipse de manière à faire correspondre les répertoires. Une fois décompresser, il vous suffira de redémarrer Eclipse pour que votre plugin soit pris en compte.

Configuration des plugins

De manière générale, les configurations dans Eclipse se font dans le menu Window>Preferences...

Gérer sa configuration

Pour connaître la liste des plugins installés, il suffit d'aller dans le menu Help>About Eclipse Platform. Pour désinstaller ou inhiber un plugin Help>Software Updates>Manage Configuration

Configuration de PHPEdit

Ce billet s'adresse à tout ceux qui cherchent une alternative Open Source à l'environnement Zend Studio. L'environnement qui a retenu mon attention est PHPEclipse. Comme Zend Studio il repose sur Eclipse, il s'agit d'un plugin à installer.

Installer l'environnement AMP

Avant de configurer PHPEclipse il faut avoir installer l'environnement AMP (Apache, Mysql, PHP) sur votre poste. Deux possibilités s'offrent à vous :

  1. Installer une distribution pré-packagée de AMP comme XAMPP
  2. Configurer les différents éléments par vos propres moyens (présenté dans ce billet)

Installer le plugin PHPEclipse

Après avoir installer l'environnement Eclipse (disponible sous licence EPL) vous avez le choix entre les deux modes d'installation :

  • via le mode d'installation à distance
  • après avoir téléchargé le plugin

Ces deux modes d'installation sont présentés sur le site de PHPEclipse dans la rubrique installation, ou dans ce billet

Configurer le plugin PHP Eclipse

Tout se passe dans le menu window>Preferences d'Eclipse

Interfacer Eclipse et AMP

Pour les utilisateurs de XAMPP comme pour ceux qui ont installé les différents modules séparément, il suffit d'indiquer les emplacements des répertoires d'installation des différentes composantes dans PHPEclipse>PHP External Tools Attention pour pouvoir démarrer Apache j'ai dû modifier l'option de démarrage en remplaçant -c "DocumentRoot {0}" par -k start. De ce fait l'option "Document Root" ne sera plus prise en compte, mais notre serveur démarrera... Il est maintenant possible de gérer le démarrage et l'arrêt de ces composants via ala barre d'outil d'Eclipse phpEditToolBox

Configuration des projets

Dans le menu PHPEclipse>Project Defaults, il vous suffit de renseigner :

  • L'URL a renseigner pour tester votre projet. Si vous travaillez avec Zend Framework indiquez http://localhost/ à condition que le DocumentRoot d'apache pointe sur le répertoire de votre projet. Sinon il vous faut définir un Alias (à condition de ne pas travailler avec Zend Framework) ou un virtual host au niveau de la configuration d'Apache. Pour plus d'information, consultez cet article
  • Laissez le "Document Root" inchangé puisqu'il n'est pas pris en compte
  • Dans la partie Include Path, vous pouvez renseigner tous les emplacements où on été placées vos librairies (Zend, PEAR, etc.)

jeudi 7 août 2008

Tester une application web

Lorsqu'on développe une application web il est souvent plus aisé de la tester localement avant de la mettre en gestion de conf. Pour tester votre application localement il vous faut un serveur web (Apache, IIS, etc.) et il se peut que vous utilisiez un environnement de développement (Eclipse, IntelliJ, NetBeans, etc..), nous utiliserons ici Apache et Eclipse pour illustrer ce billet.

L'objet de ce billet est de vous proposer des méthodologies pour tester votre application web localement...

Premier constat : le répertoire de travail est différent du répertoire de déploiement

Dans ce cas plusieurs solutions s'offrent à vous :

  1. Fusionner les deux répertoires
  2. Copier le contenu du répertoire de travail dans le répertoire de déploiement
  3. Faire en sorte que le serveur web pointe sur le répertoire de travail
  4. ...

Avant de détailler chacune de ces solutions, il convient de rappeler que ces répertoires pour Apache et Eclipse sont : APACHE_HOME/htdocs et ECLIPSE_HOME/workspace/Project_name

Fusionner les deux répertoires

Certainement la solution la plus immédiate, au démarrage d'Eclipse il suffira d'indiquer le répertoire APACHE_HOME/htdocs comme répertoire de travail. Cette solution nous assure de tester les bons fichiers et dans leur dernière version, toutefois l'inconvénient que je note dans cette solution vient des fichiers qui n'ont rien à faire dans l'environnement de test : .project pour Eclipse, code source pour les langages compilés, etc. En plus le serveur web devient difficilement utilisable pour plusieurs projets en parallèle.

Copier le contenu du répertoire de travail dans le répertoire de déploiement

Cette approche est intéressante car elle permet au développeur de sélectionner les fichiers à déployer et donc à tester. L'inconvénient immédiat est bien entendu de systématiser le déploiement avant les tests pour éviter de tester des fichiers obsolètes... Pour cette solution il convient de mettre en place un petit script de déploiement pour faciliter la tâche du développeur. Le framework ANT est souvent utilisé pour effectuer ce genre d'opération, exemple

<project name="deploiement" basedir="." default="deploy">
        <property name="targetDir" value="C:\apache\htdocs\test" />
        <target name="deploy">
                <delete dir="${targetDir}" />
                
                <mkdir dir="${targetDir}"/>
                
                <copy todir="${targetDir}">
                        <fileset dir="." includes="**\*.php"/>                                
                </copy>
        </target> 
</project>

le serveur web pointe sur le répertoire de travail

Cette opération est me semble t-il la plus intéressante car les ressources sont à un seul endroit (dans le répertoire de travail). De plus comme le serveur web peut référencer plusieurs répertoires de travail on peut travailler sur plusieurs projets en parallèle. Certains plug-ins de vos environnements de développement vous permettent d'automatiser cette opération (PHPEclipse, PDT, WTP, etc...). Mais ayant souvent rencontré des problèmes, je décris ici comment paramétrer votre serveur web pour qu'il référence votre répertoire de travail.

Définir le répertoire de travail et ses droits

Cette opération se fait dans le fichier de configuration du serveur web. Pour Apache, il s'agit du fichier APACHE_HOME/conf/httpd.conf dans lequel le répertoire se définit de la manière suivante :

<Directory "C:\eclipse\workspace\Test">
   Options Indexes MultiViews 
   AllowOverride All
   Order allow,deny
   Allow from all
</Directory>

A l'intérieur de la balise <Directory>, il est possible de spécialiser les droits qu'auront les utilisateurs sur ce répertoires. Si rien n'est spécialiser ce sont les droits par défaut qui s'appliquent. Pour plus d'information sur la balise <directory> se référer au site d'Apache

Référencer le répertoire de travail

Cette opération peut se faire de deux manières dans le fichier httpd.conf : via un Alias ou un VirtualHost

Un alias est un bout d'URL à placer juste après http://IP_DU_SERVEUR:PORT/ALIAS pour pointer sur votre répertoire de travail. Il se définira ainsi dans le fichier httpd.conf

Alias /www "C:\eclipse\workspace\Test"

Ainsi vous accèderez à votre répertoire de travail en tapant l'adresse suivante : http://127.0.0.1:80/www

Un VirtualHost est intéressant lorsqu'on veut faire cette aiguillage sur un nom le nom de domaine ou le numéro de port. Pour mettre en place un tel aiguillage il nous faut déjà un système pour résoudre les noms de domaine : serveur DNS à l'échelle d'Internet ou fichier Host à l'échelle de votre machine. Ici nous présenterons le second cas en étant bien conscient que la portée est locale (mais c'est bien se que nous cherchions initialement, non?). Si vous êtes sous windows il vous faut éditer le fichier suivant : C:\Windows\System32\drivers\etc\hosts pour lui ajouter la ligne suivante :

127.0.0.1       local.mywebapp.com

Ainsi lorsque vous taperez http://local.mywebapp.com/ dans votre navigateur ce sera équivalant à http://127.0.0.1

Maintenant effectuons l'aiguillage dans le fichier httpd.conf, pour celà complétez le comme suit :

<VirtualHost local.mywebapp.com:80>
    DocumentRoot C:\eclipse\workspace\Test
    ServerName local.mywebapp.com:80
    ErrorLog logs/jc.log
    CustomLog logs/jc.log common
</VirtualHost>

Notez qu'en plus de l'aiguillage, il vous est possible de spécifier les fichiers de log dans lesquels seront consignés les erreurs et autres messages de votre application, pratique pour avoir un fichier de log par application! Pour plus d'information sur les VirtualHosts référez vous à ce document sur la documentation Apache.