L'un des principes de l'agilité est de mettre en place des mécanismes automatisés de détection d'erreurs. Le but est de détecter le plus tôt possible des erreurs afin de minimiser la génération de problèmes induits. L'automatisation des tests permet aussi de décharger le développeur. Le format XHTML a l'avantage de faciliter la mise en place de tels mécanismes par rapport à son homologue HTML. Voici les explications. En quelques mots
XHTML facilite la détection des erreurs pour les raisons suivantes:
- Les navigateurs qui supportent le XHTML affichent les erreurs de syntaxe XML.
- On peut utiliser un parser XML pour repérer les erreurs de syntaxe XHTML.
Détecter les erreurs de structure du document WEB évite bien des problèmes de comportement des navigateurs. Il n'est pas rare d'avoir un bug Javascript et de passer un temps énorme à trouver que l'erreur était indirectement liée à une faute de frappe. Idem avec les CSS qui se mettent à faire n'importe quoi à cause d'une balise mal fermée. L'erreur est humaine et nos tests automatisés peuvent nous aider à les détecter.
Les points qu'il faut travailler pour mettre en place ces mécanismes sont:
- Le choix du standard pour la structure du document.
- La négociation de contenu par le serveur.
- La configuration et l'intégration d'un parser XML au sein des tests Selenium.
Le choix du standard XHTML
Tous les navigateurs modernes supportent le XHTML strict avec le content-type "application/xhtml+xml". Et ça depuis pas mal de temps déjà. Les plus importants d'entre eux sont Firefox, Safari, Opera et le dernier Chrome. Ils représentent à peu près 30% à 40% des parts de marché dans le monde. (plutôt 40% en Europe et plutôt 30% aux états-unis)
Oui mais dans le contexte commercial que connait le WEB aujourd'hui, il ne faut pas oublier le vieux Internet Explorer qui représente donc entre 60% et 70% du marché mondial toutes versions confondues. Pour la petite histoire, je ne considère pas IE7 ni IE8 comme des navigateurs modernes du fait qu'ils ne supportent toujours pas le content-type "application/xhtml+xml". IE n'implémente pas de rendu XHTML, il utilise son mode de rendu HTML pour afficher les pages WEB.
Dans ce contexte, la solution la plus élégante est de choisir le standard XHTML1.0 strict. Le W3C a prévu le passage en douceur (Ça ne fait que huit ans, il ne faut pas brusquer Microsoft, sic!) pour la transition de HTML vers XHTML. En effet le standard XHTML 1.0 autorise l'utilisation du content-type "text/html" ou "application/xhtml+xml".
Parfait, avec XHTML1.0 nous avons un candidat idéal pour être utilisé à la fois par IE, et par les navigateurs modernes avec lesquels nous allons pouvoir profiter du plein potentiel de cette norme.
La négociation de contenu
On appelle agent utilisateur, tout système permettant d'interpreter une page WEB, par exemple les navigateurs WEB, les systèmes vocaux, brailles ou les téléphones portables 3G.
Une fois les pages WEB créées il faut implémenter un mécanisme de négociation qui va permettre d'envoyer le content-type "application/xhtml+xml" aux agents utilisateurs qui savent le gérer. Si l'agent utilisateur ne sait pas le gérer il faut dans ce cas envoyer le content-type "text/html".
Il existe différentes façon de faire de la négociation. Voici un exemple de configuration du serveur Apache. Mais dans le monde JEE il est sûrement plus judicieux de tester les entêtes HTTP au niveau de la Servlet. Il suffit de tester si l'on trouve la chaine de caractères application/xhtml+xml dans l'entête HTTP "HTTP_ACCEPT". Si cette chaine s'y trouve, on envoie le content-type "application/xhtml+xml". Dans le cas contraire, on envoie "text/html".
C'est important d'implémenter la négociation de contenu car une page XHTML servie à un agent utilisateur avec le type MIME "text/html" serait parser comme du HTML et on ne bénéficierait donc pas de la détection des erreurs XML. Il serait également plus difficile de valider le document car on ne pourrait pas passer par Selenium.
Valider le flux XHTML au sein des tests Selenium-RC.
Selenium-RC n'étant pas le sujet de ce billet nous partons du principe que vous avez déjà un environnement qui permettent de l'utiliser. Selenium-RC permet d'effectuer des tests fonctionnelles d'une interface WEB. Nous pouvons profiter de cette infrastructure pour rajouter facilement un test de validation XHTML sur les pages visitées.
L'idée est d'ouvrir une page WEB avec selenium comme habituellement et d'injecter du javascript qui permettent de retrourner le DOM sous forme de flux XML. Une fois ce flux récupérer il suffit d'utiliser le parser XML Java en activant la validation.
Récupérer le DOM sous forme de flux XML
On part du principe que le navigateur utilisé pour les tests est Firefox. Dans ce cas le code pour récupérer le flux XML du DOM est le suivant:
String xmlString = seleniumClientInstance.getEval(
"if (this.browserbot.getCurrentWindow().document"
+ "instanceof XMLDocument) {"
+ "new XMLSerializer().serializeToString("
+ "this.browserbot.getCurrentWindow().document);"
+ "}");
Valider le flux XML avec la DTD XHTML1.0 strict
L'utilisation du parser XML interne à Java est suffisant pour cette opération. Vous pouvez suivre cet exemple pour savoir comment parser un flux XML. Suivre les étapes suivantes:
- Récupérer la DTD et la copier dans le classpath
- Créer une classe qui implémente org.xml.sax.EntityResolver et l'injecter dans le DocumentBuilder en utilisant sa méthode setEntityResolver. Elle permettra au parser de retrouver la DTD si la connexion Internet ne le permet pas.
- Créer une classe qui implémente com.cl.fwk.test.xml.DefaultHandler afin de gérer proprement les erreurs de syntaxe XML et XHTML lorsqu'elles seront détectées. Injecter cette classe dans le DocumentBuilder en utilisant sa méthode setErrorHandler
- Et parser le flux XML avec votre DocumentBuilder, que vous venez de configurer, en utilisant la methode parse comme indiqué dans le lien précédent.
DocumentBuilder builder = fabrique.newDocumentBuilder();
builder.setEntityResolver(new MonEntityResolver());
builder.setErrorHandler(new MonErrorHandler());
builder.parse(
new ByteArrayInputStream(xmlString.getBytes())
);
Le mot de la fin
Nous venons de voir comment profiter de l'architecture mise en place pour Selenium-RC afin d'étendre les tests aux structures des documents WEB de nos applications.
J'espère que cet exemple vous permettra d'améliorer la qualité de vos applications WEB.
Si j'ai un dernier conseil à donner suite à mon expérience sur le terrain: Faites en sorte que les erreurs XHTML ne fassent pas passer les tests. Ça obligera à corriger ces problèmes, sinon ça finira par tomber aux oubliettes.
]]>
Vous mettez en oeuvre les méthodes agiles, vous êtes intéressé par ces méthodes ou vous en avez juste entendu parler et avez envie de découvrir ce monde émergeant ?