Aller au contenu | Aller au menu | Aller à la recherche
mercredi 6 juillet 2011
Par julien le mercredi 6 juillet 2011, 00:24
Fourni par Google à la fondation Eclipse, WindowBuilder est un excellent plugin pour réaliser des interfaces graphiques. Avec le support des API SWT, JFace, Swing, RCP, XWT et GWT, contrairement aux plugins comme JIgloo ou VE, il s'avère extrêmement stable.
Pour plus d'informations : http://code.google.com/intl/fr-FR/javadevtools/wbpro/index.html
mardi 10 février 2009
Par julien le mardi 10 février 2009, 19:01
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
Par julien le lundi 9 février 2009, 09:57
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. 
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.
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
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());
}
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
Par julien le samedi 7 février 2009, 18:05
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.
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.
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 :
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)
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.
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.