Après cette accroche quelque peu racoleuse, je m’explique :
JsUnit est un outil permettant de tester ses fonctions écrit en JavaScript. C’est tout simplement l’équivalent Javascript de JUnit. J’ai programmé mes tests au fur et à mesure en utilisant Firefox, puis à la fin de la semaine, je me suis rappelé l’existence d’Internet Explorer. Au vu des résultats, je me suis dit que la compatibilité présumée de Prototype envers FF et IE allait prendre du plomb dans l’aile. Il m’a donc fallu chercher l’origine de ces bugs.

Première partie : des variations minimes mais suffisantes

Les lecteurs avisés me diront que je ne teste pas la même chose, puisque j’ai 56 tests sur FireFox et 59 sur IE. C’est parce que JUnit sous IE s’amuse à évaluer des fonctions telles que celle-ci :

Avec Prototype, j’ai étendu l’objet Element pour y mettre la fonction getParentElement() qui renvoit le paragraph le plus proche de l’élément.
J’utilise donc la ligne : parent=element.up(".paragraph");

IE me renvoit une erreur "Not Implemented". Je pensais qu’il y avait une erreur avec l’implémentation de up() par Prototype mais en fait mÔnsieur Internet Explorer n’accepte pas le nom de variable parent. Essayez parent="" ou parent="java" et vous aurez une erreur "Not Implemented".

En déclarant la variable var parent="", tout va mieux.

Il faut ensuite savoir que lorsque vous écriver du code HTML, les moteurs de Firefox et IE les réécrivent derrière vous. Cela se voit en utilisant alert(monElement.innerHTML). J’ai repéré deux problèmes notables :

Internet Explorer réécrit au lieu de . Les guillemets de l’attribut value disparait : ce qui fait que value n’est d’ailleurs plus un attribut au sens xml. Assez génant pour les tests unitaires tels que celui-ci :
assertTrue (divControllers.innerHTML.include(‘ value="I" ‘));

Internet Explorer réécrit ses balises en majuscules. InnerHTML renvoit H3 au lieu de h3. Il faut donc réécrire les tests :
assertTrue(divForm.innerHTML.toLowerCase().include(‘h3′));
au lieu de :
assertTrue(divForm.innerHTML.include(‘h3′));

Deuxième partie : Le XML avec Prototype

Dans mes tests unitaires, j’utilise une String :

Et je teste ma fonction sensée recevoir transport.responseText.

Une fonction utilisant transport.responseText est à priori plus facile à tester qu’une autre utilisant transport.responseXML.

result.select("firstname")[0].innerHTML fonctionne très bien sous FireFox et me renvoit « Nicolas ». Mais sous IE, impossible de parser un élément non inscrit dans le document ! Prototype fonctionne bien, mais considère, sous IE, result comme une string, et pas comme un ensemble d’élément organisés en arbre. Il est donc nécessaire de passer par responseXML et d’ignorer ici les avantages de Prototype.

Le test unitaire de la fonction traitant le résultat devient plus compliqué : le Mock object n’est plus une String mais un document. Si vous avez une petite fonction fiable transformant mon String en document XML, je suis preneur.

Finalement, on y arrive.