Discussion :

[GLDavid]

Bonjour

La question est simple si je puis dire. J'ai développé une application et je valide le code par des unit tests (JUnit 3.8). La seule chose qui me pose problème est l'interface graphique. Pouvez-vous me conseiller sur comment s'y prendre pour appliquer des unit tests sur une interface graphique ?
Est-ce finalement nécessaire ?
Merci d'avance de vos réponses.

@++

[gifffftane]

Je trouve que c'est nécessaire, mais il est difficile de régler ce qui doit être testé.

Pour le faire, j'ai commencé par jemmy, puis je me suis aperçu que j'avais meilleur compte à tout faire moi même. Donc je n'utilise plus que le swing standard, je n'ai même pas de bibli perso.

Dans tous les cas, cela nécessite une bonne connaissance de swing.

[djsnipe]

Après quelques tentatives de prototypage d'une solution de test unitaire d'IHM Web, j'ai considéré que c'était finalement inutile dans ce contexte. Ou plutôt inadapté (pour éviter d'en faire hurler certains).
Ces tests sont très lourds à coder pour du WEB (vérif de code html, problèmes si du javascript génère du html ... une horreur), est très dur à tester unitairement si tout un enchainement est nécessaire pour arriver à une page donnée, et ne peux pas vérifier le rendu visuel final qui est primordial. Et pour le Swing ou le HTML, l'apparence sur un redimensionnement, c'est dur à automatiser (ok, pas impossible pour le Swing).

Je préfère donc maintenant quand c'est nécessaire (grosses phases de non regression sur de grosses appli) mettre en place des outils qui font de la capture d'interactions clavier/souris avec l'appli pour l'aspect fonctionnel de l'interface. Le rendu est toujours contrôlé par une personne physique, et dans les projets web, souvent en multi navigateurs (j'aime le web ).

[guigui5931]

Pour les applications web il y a Selenium qui marche très bien.

[simon.brandhof]

et pour les tests de non-régression Swing, il y a JDiffChaser

[GLDavid]

Bonjour

Merci de vos réponses. Si je résume vos dires, il apparaît que tester unitairement une IHM est difficile, chose qui était décrite dans d'autres forums tels que celui de Sun.
Toutefois, je jetterais un regard sur les solutions que vous proposez et je pense que rédiger un scénario de test fonctionnel sera la meilleure solution.
J'attends d'autres avis avant de clore ce thread.
Merci encore à vous.

@++

[gifffftane]

Heu... il faut s'entendre sur le sens du mot difficile.

Difficile techniquement (comment faut-il tester ? ), oui, mais formateur. Tu pourrais aussi bien dire Tester une IHM est formateur. Peut être n'auras-tu pas le même regard.

Difficile conceptuellement (que faut-il tester ? ), oui aussi, mais là on souffre de la culture ambiante (cette épouvantable notion de couverture de test, par ex.) complètement à coté de la plaque pour les IHM. Il vaut mieux, à mon humble avis, partir de la notion Qu'est-ce qui est sensible pour l'utilisateur ou pour le développeur ?

Et puis aussi les tests IHM ne sont nullement limités aux tests unitaires. Il peut très bien y avoir des tests d'intégration impliquant l'IHM, heureusement.

[djsnipe]

Et puis aussi les tests IHM ne sont nullement limités aux tests unitaires. Il peut très bien y avoir des tests d'intégration impliquant l'IHM, heureusement.

En effet, même si pour ma part je limiterai les tests IHM aux tests d'intégration (automatisés ou non selon la taille du projet) et les aspects dits sensibles aux développeurs et utilisateurs se retrouvent dans des tests unitaires des services appelés par la couche graphique. L'intégration des services avec les IHM est fait par test unitaire manuel lors des développements en plus des tests visuels sur l'aspect.

[gifffftane]

Oui, je ne sais pas si c'est ce sur quoi djsnipe voulait insister, mais en tous les cas j'y insiste : dans le domaine des tests GUI (comme dans tous les autres d'ailleurs) il doit toujours y avoir complémentarité entre les tests automatiques et les tests manuels, jamais opposition ; les tests automatiques ne doivent jamais être un prétexte pour dire C'est passé, donc c'est bon.. (et encore moins les tests manuels, d'ailleurs).

Ce que demande le client est que l'application marche, non pas que les tests marchent.

Aussi il faut s'entendre sur le sens des termes : par test unitaire, j'entends plus volontiers test d'une classe java, et non tests unitaires de service : ça c'est plutôt de l'intégration, pour le codeur, puisque un service implique en général plusieurs classes, et même plusieurs couches (base de données, etc).

Mais ce qui se conçoit clairement s'exprime sans difficulté du moment auquel on se comprend bien dans ce que l'on veut dire et qui est bien d'accord.

Et c'est vrai que, la plupart du temps, les tests IHM sont en fait du niveau intégration, puisqu'ils impliquent la monopolisation de la ressource écran-clavier-souris, forcément. Ils sont unitaires (à mon sens) lorsqu'ils se limitent au niveau M du MVC.

[super_navide]

Pour tester une éfficacement une IHM il faut qu'elle réponde le mieux possible au model MVC (Model Vue Controlleur)
Tu test via des JUnits ton model puis quelque tests manuel sur l'IHM.
Le plus gros des tests sont à faire sur le Model car si le Model ne fonctionne pas correctement alors forcement ton IHM ne fonctionne pas aussi

Le model contient toutes le comportement metier de ton ihm.

[tosirap]

Salut,

Je te conseille Squish For Java (http://www.froglogic.com/pg?id=Produ...ns&subsub=java).

J'ai utilisé cet outil pour effectuer des tests fonctionnels pour une lourde appli SWT, c'était très efficace.

A+

[longbeach]

+1 pour Selenium.

[supermanu]

+2 pour Selenium

Selenium va te permettre d' "enregistrer" les manipulations que tu fais avec ton navigateur : clique sur un lien, remplissage d'un formulaire, submit d'un formulaire.... Puis de rejouer ce que tu as enregistré.

Avantages :
- le plus gros avantage que je vois c'est la possibilité d'être feignant
Imagine que ton application comporte par exemple une fonctionnalité "créer un compte" qui se fait sur 3-4 formulaires successifs et où il faut remplir plein de champs... Avec Selenium, tu le fais une fois en enregistrant. Puis tu relance ce scénario à chaque fois que tu veux tester la fonctionnalité...

Inconvénients :
- Il faut que le code HTML soit "bien fait". C'est à dire que les champs comportent des id par exemple. Selenium offre d'autres moyens de trouver des champs (position, style css...) mais il risque d'en oublier quelque uns à l'enregistrement...

- Les tests que tu vas pouvoir faire pour vérifier que ta vue fonctionne correctement vont être du style : "est-ce que la page comporte le texte xxxxxx ?" "est-ce que l'image yyyyyy est bien affichée ?"
Donc comme on le voit, tout ce joue sur la vue. Et dans certains projets, les vues sont très souvent modifiées....

donc à toi de voir suivant le type de projet, la complexité des vues....

[eracius]

Selenium parait très intéressant et peut permettre de mettre en place une première batterie de tests simples.

Mais je pense que le mieux reste le test par l'utilisateur ou au moins par une personne étrangère au développement.

Pour ma part, je fais tester mon interface web par un collègue, non informaticien, qui parvient toujours à mettre le doigt sur les petits problèmes et autres incohérences qui m'aurait échappées. Après, cette démarche est très couteuse en temps mais m'a permis jusqu'à présent de limiter très fortement les retours de bug une fois l'application déployé chez le client.

Néanmoins mon interface n'est utilisé que par un nombre réduit de personnes ce qui me permet donc d'être très réactif en cas de problème. Pour une application grand publique, je suppose que des tests beaucoup plus exhaustifs seront nécessaires pour être sur de ne pas crouler sous les rapports de bugs et ça peut rapidement devenir un vrai casse tête sans une bonne organisation (scénarios prédéfinis pour que le testeur gagne du temps et compagnie).

[schneidb]

+1 pour selenium qui marche je crois sous firefox.
Sur internet explorer il y a iMacros.

[rroommuu]

Selenium fonctionne aussi bien avec IE qu'avec FF. Par contre, le plug-in permettant d'enregistrer les tests n'est disponible que pour firefox.

[nicolav]

Pour des tests sur interface graphiques, tu peux utiliser des frameworks de tests tels que marathon ou encore Fest.
J'ai utilisé ce dernier pour des tests sur un logiciel. Je vérifiais si des JOptionPane s'affichaient bien, si le texte dedans était le bon...
ça marchait plutôt bien.

[Laurent Tardif]

Alors pour apporter une reponse qui t'aidera j'espere
1) oui et plusieurs fois oui, les tests sur une IHM sont utils, par contre, ils sont difficile a mettre en place et a maintenir si on ne fait pas attention.
2) des regles de codage peuvent simplifier leur ecriture : id uniq sur les elements HTML resultant, .... convention de nomage sur les form, ...
3) les tests doivent essentiellement tester la navigation, le comportement, pas le look & feel (tu peux verifier la presence d'elements, que ton html est bien formé, test java script ont une bonne syntaxe) mais pas plus.
Selenium (IDE/RC/GRID) te premettra d'automatiser tout ca relativement simplement.
4) bien evidement, faire des scenarios de tests reproductibles et automatisable