1- Pourquoi des test d'IHM ?
Travaillant sur des sites internet en Java, j'ai été amené à faire des tests d'IHM automatisés. Mais pourquoi des test d'IHM ? En effet on peut utiliser JUnit sur une grande partie du code, on peut se servir de Fitnesse pour faire des tests d'intégration / fonctionnels mais est-ce suffisant avec un site web ? A la recherche d'une meilleure ergonomie, d'une plus grande fluidité dans les pages on fait de plus en plus appel à des traitements Ajax, donc côté client/navigateur. Par exemple, en cliquant sur un bouton, il va changer de couleur et un bloc de texte va apparaître, le tout en soumettant un formulaire sans recharger la page...

Les méthodes de test que nous utilisons d'habitude ne sont d'aucune utilité pour garantir la robustesse de notre système. Pourtant nous devons être sûr qu'en changeant un bout de code javascript, ou une partie de l'ihm (page JSP ou page statique), les différentes cynématiques du site fonctionneront toujours... et sur tous les navigateurs... Et voilà qu'interviennent les tests d'IHM !

2- Qu'attendons nous d'une plateforme de tests d'IHM ?

  • Que les tests soient "faciles" à écrire et à mettre à jour justement dans le cas où l'IHM est modifiée.
  • Qu'elle permette de tester l'application sur différents navigateurs (IE, Firefox, Chrome, ...), et différents OS. Ceci afin de couvrir les problèmes incontournables de compatibilité javascript/css entre les navigateurs !
  • Cette plateforme doit être capable de tester les parties Ajax du site.
  • Les tests doivent être automatisés ! Sinon cela ne sert à rien. On doit pouvoir être avertit très rapidement qu'une modification de code a provoqué un bug sur le site.
  • La plateforme doit fournir un reporting des tests en erreur.


3- Quelles sont les solutions existantes ?

Selenium (solution 1)

Selenium permet avec son add-on Firefox de construire des tests IHM. Le format de sortie est une page Html pour chaque test. On peut rejouer les tests à l'aide de l'add-on Firefox. Il est surement possible de jouer ces tests de manière automatique. Cependant les inconvénients ci-dessous m'ont dissuadé d'aller plus loin dans cette voie :

  • si l'interface change, il faut changer tout le test
  • impossible d'agir de manière programmatique sur le test (comme par exemple injecter des données dans une base ou utiliser "facilement" des variables)

Selenium (solution 2)

L'add-on Firefox, permet de convertir les test IHM en Java (test JUnit ou TestNG), à partir du fichier Html. On peut dans ce cas là utiliser des variables, factoriser des méthodes...
Et avec l'aide de Selenium RC et Selenium Grid il est possible de mettre en place une bonne plateforme de tests.
Cependant il y a un gros inconvénient : Pour avoir des tests maintenables vous allez devoir factoriser du code, réfactorer... et tout ceci à la main ! Car tout est mélangé : le code servant à définir l'interface et celui permettant de tester l'interface...

Tellurium

Tellurium permet de séparer complètement la définition de l'interface des tests à exécuter. En effet dans un premier temps, on va définir l'agencement des différents éléments composant l'interface (boutons, formulaires...) ainsi que les méthodes "fonctionnelles" s'appliquant à cette interface (rechercher ce mot sous Google, récupérer le résultat de la recherche ...). Et dans un deuxième temps on va construire des tests unitaires qui vont faire appel à ces méthodes fonctionnelles.
Par conséquent si l'interface change, on modifie une toute petite partie du code, sans impact sur les tests déjà créés.
D'où le réel avantage de Tellurium : séparer la définition de l'interface utilisateur du test en lui même !

La création d'un test simple avec Tellurium se fera dans un prochain billet ;-)