Premier webinar de cette série: Présentation de jDiffChaser, une aide à la non-régression des rendus d’interfaces.

Durant cette présentation d’une heure environ, j’aborderai la problématique de régression de rendus d’interfaces que nous avions au sein de notre équipe de développement (interface de contrôle aérien). Nous parlerons ensuite de l’approche qui a été choisie pour avoir une aide automatisée puis détaillerons les possibilités de jDiffChaser, produit développé en interne et devenu Open Source.

Je vous invite donc à vous connecter le vendredi 17 avril à partir de 14h (heure locale Genève), à l’adresse suivante: http://conferences.hortis.ch/dimdim/

La room s’appellera jdiffchaser et le nombre de places sera limitée à 20 personnes.

Il vous faudra saisir une clé qui vous sera fournie le jour même par mail. C’est pourquoi je vous invite à vous inscrire ici.

Cette nouvelle version de Netbeans apporte son lot de nouveautés dont les principales sont:

• Support PHP
• Support JavaFX

Vous trouverez plus de détails en vous rendant à http://wiki.netbeans.org/NewAndNoteWorthyNB65

En ce qui me concerne, je suis surtout content que le support de Clearcase ait été bien amélioré. Il y’a d’autres petites nouveautés dans l’éditeur qui améliorent l’ergonomie et le confort d’utilisation.

J’ai profité de l’occasion pour mettre à jour le plugin pour Netbeans de notre layout manager: Koala layout. J’ai ajouté le support des “insets”. Dorénavant ils sont correctement traités et ils apparaissent lors des déplacements/resizing des composants Swing comme vous pouvez le voir sur l’image ci-dessous:

Je vous invite à aller récupérer la dernière version à https://koalalayout.dev.java.net/ ou en passant par l’update center: https://koalalayout.dev.java.net/nbm/updates.xml

C’est mon premier post sur le site et j’espère le début d’une longue série (ce ne sont pas les idées qui me manquent)!

Notre équipe horticienne vient de publier un nouveau projet en open-source qui est issu de notre travail chez et avec un client: KoalaLayout. Il s’agit d’un layout “grille” amélioré pour Swing. Le KoalaLayout est bien plus pratique à utiliser que le GridLayout livré en standard par Swing qui souffre d’un certain nombre de limitations.

De plus le projet contient un plug-in pour Netbeans 6 qui permet de mettre oeuvre très facilement le Koalalayout dans l’éditeur graphique de cet IDE et de l’utiliser dans vos projets.

Rendez-vous sur le site koalalayout.dev.java.net pour plus de détails et pour récupérer le code.

Happy coding!!

En effet nous utilisons un produit annexe comme date picker depuis quelques années et il semblerait que son rendu diffère entre les deux versions. Certes l’allure diffère, mais la locale semble prise en compte de manière différente. Alors, mauvais usage de notre part ou comportement différent du composant sous java 1.6? Peu importe, le principal était de détecter le plus rapidement possible ce soucis avant la prochaine mise en production D’autant plus que nous ne l’avions pas remarqué auparavant en “jouant” avec l’application (avant de choisir de lancer nos tests jDiffChaser sous 2 jdks différents)… Comme quoi…

Cela fait maintenant deux petites semaines que la dernière version est lancée sur sourceforge, la 0.8 donc, que l’on utilise régulièrement depuis un mois. Au programme de cet opus:

• La gestion des redémarrages des applications remote a été revue,
• La compatibilité MacOS (demandée par certains utilisateurs)
• Les screenshots full-screen
• Délais possibles avant les screenshots (pour pouvoir enregistrer, par exemple, des éléments visuels présents uniquement si le pointeur est à un certain endroit)
• La transparence de la télécommande d’enregistrement (pour voir l’interface lorsque l’on enregistre une application full screen)
• L’enregistrement des mouvements des dialog boxes
• Une amélioration dans la navigation du rapport résultant de l’exécution des comparaisons

Pour rappel, jDiffChaser permet d’automatiser la comparaison visuelle de deux versions d’une application Swing (généralement la dernière en production et celle en développement) selon une liste de scénarios temps réel enregistrés par les testeurs. On détecte ainsi les effets de bords d’un composant visuel modifié et utilisé dans plusieurs écrans de l’application. Il arrive que certains de ces écrans aient été oubliés d’être checkés manuellement par le team de développement après modification du composant, l’automatisation via jDiffChaser palie à ces failles. Les zones que l’on ne veut pas comparer peuvent être définies comme “à ignorer” d’une action de souris, lors de l’enregistrement du scénario.

Libre à vous de choisir d’utiliser cet outil soit pour chasser les régressions visuelles soit pour visualiser et lister les changements entre versions.
Un exemple ci-dessous de comparaison hardue à l’oeil nu:

-

-

-

-

Qu’est-ce que jDiffChaser?

Un outil Open Source permettant d’automatiser les comparaisons visuelles d’écrans entre deux différentes versions d’un même logiciel arborant une interface Java Swing. Le même écran est “vu” par jDiffChaser:

1. lorsqu’il est rendu par la dernière version validée de l’application
2. lorsqu’il est rendu par la version en développement.

Puis il compare les deux images et en trouve les différences.

Les scenarios sont des enregistrements d’actions de l’utilisateur et le déroulement de ceux-ci peut se faire, soit en mode séquentiel (mode le plus courant) soit en mode parallèle sur deux machines distantes (pratique si le rendu de l’application est dépendant de données temps réel: à noter que c’est le mode que j’utilise tous les jours chez mon client).

A quoi ça sert?

A éviter les surprises entre deux versions: régressions et autres “undocumented features” visuelles.

Qui a besoin de ça, et pourquoi?

Par exemple des applications où chaque couleur, emplacement, taille de police a son importance, une signification: contrôle ferroviaire ou aérien par exemple.

Mais pas seulement. Les applications où la réutilisation de composant est importante aussi: un composant retravaillé peut parfois avoir des répercussions visuelles sur tel ou tel autre écran de l’application.
jDiffChaser peut encore être un moyen de tracer justement les évolutions visuelles entre deux versions.

Et c’est utilisé?

Oui, toutes les nuits depuis plus d’un an chez mon client. Depuis que l’on utilise cette méthode (depuis le début du printemps 2006), jDiffChaser nous a remonté une bonne dizaine d’impacts visuels cachant de gros bugs aux conséquences pas très sympathiques en cas de livraison. Nous nous en servons aussi comme listing visuel des évolutions graphiques entre versions.

Juste une dernière question, pourquoi une comparaison visuelle?

Vous avez certainement déjà expérimenté le problème des “…” à la fin du texte d’un composant Swing. Les frameworks de test d’interfaces “classiques” (comprendre non-visuels) répondront tous que le texte du bouton est bien “Cancel”, mais aucun ne peut valider le fait que “Cancel” est bien affiché à l’écran. On peut vite se retrouver avec “Can…” à cause d’un bouton devenu un peu trop petit. jDiffChaser ne permet pas non plus de valider seul que “Cancel” est bien affiché, mais il pourra confirmer que le rendu du bouton a changé entre les versions, c.q.f.d. pour les besoins de non-regression que nous avions.

Alors je peux oublier tous les autres frameworks de tests d’interfaces?

Ne faites pas ça! A chaque problématique son produit. Tester les fonctionnalités, les données d’une application, demande un framework comme Abbot, UISpec4J, Jemmy ou autre. Tester le rendu et la non-régression de celui-ci est un travail pour jDiffChaser.

Pour plus d’informations…

Je vous invite à parcourir le User’s Manual contenu dans l’archive, il décrit un exemple “prêt-à-exécuter” qui est aussi livré dans le package.
Page Sourceforge du projet