XMLUnit

Parmi les outils implémentant un algorithme de type diff2 _{adapté aux arbres XML,}

nous avons pu voir dans le Chapitre II que XMLUnit était le meilleur candidat vis-à- vis de nos attentes : accès au détail des différences identifiées, prise en compte de la similarité entre documents, etc. Nous allons ici détailler notre « détournement » de cet outil de test unitaire dédié au XML pour réaliser notre outil de détection des différences entre les fichiers XML des modèles attendu et terrain.

IV.1.2.1 Principe de fonctionnement

Par défaut, l’algorithme de comparaison de deux flux XML considère ces deux der- niers comme :

1. Identiques si aucune différence n’a été trouvée,

2. diff est un algorithme de comparaison de deux fichiers, initialement implémenté dans le système Unix.

2. Similaires si les différences trouvées sont « récupérables », c’est-à-dire qu’elles n’ont pas d’impact sur le sens des données. Les différences entrant dans ce cas sont au nombre de deux :

• Deux éléments dans les deux documents XML contiennent les mêmes éléments enfants mais dans un ordre différent,

• Un attribut dont la valeur par défaut (décrite dans le Schéma XML des deux documents XML) a été explicitée dans l’un des documents mais pas dans l’autre.

3. Différents dès qu’une des différences identifiées n’est pas « récupérable ».

IV.1.2.2 Le moteur de comparaison

La documentation de XMLUnit étant des plus succintes en ce qui concerne le fonc- tionnement du moteur de comparaison, nous avons dû nous immerger dans le code source de cet outil programmé en Java pour comprendre ses mécanismes.

Il apparaît dans un premier temps que si XMLUnit propose une classe Diff grâce à laquelle on appelle la méthode de comparaison, celle-ci n’offre pas un diff au sens UNIX traditionnel du terme (cf. Section II.2.2.1). En effet, elle permet d’évaluer la comparaison de documents XML en termes d’identité, de différence mais aussi de similarité et retourne un message décrivant la première différence trouvée (par exemple : nombre de noeuds différents, élément ajouté/supprimé, etc.).

Si l’on souhaite pouvoir accéder au détail des différences trouvées entre les deux do- cuments, il faut utiliser la classe DetailedDiff. Cette classe DetailedDiff hérite de Diff et en étend les fonctionnalités. Elle permet de comparer deux documents XML et la comparaison ne s’arrête pas à la première différence non récupérable trouvée (contrai- rement à Diff ). La classe permet d’accéder par la suite à la liste détaillée de toutes les différences rencontrées. Dans l’implémentation de notre prototype, nous utiliserons

DetailedDiff afin de pouvoir réaliser l’analyse de chaque différence identifiée.

Diff et DetailedDiff font tous les deux appel au coeur de la fonctionnalité de com-

paraison des documents XML de XMLUnit qui se trouve implémenté dans la classe

DifferenceEngine. Cette classe compare les noeuds XML (objets Node) entre eux et no-

tifie l’écouteur DifferenceListener de toute différence ou dissimilarité trouvée.

La classe DifferenceEngine fait appel principalement à la méthode compare() qui prend quatre paramètres en entrée : le noeud XML de référence (control), le noeud XML à tester (test), l’écouteur (listener) qui est notifié de toute différence détectée du- rant la comparaison des noeuds entre eux, et une interface elementQualifier qui indique au moteur de comparaison les types de données sur lesquelles effectuer la comparaison (uniquement les éléments, uniquement les attributs, les éléments et les attributs, etc.). Dans notre usage de XMLUnit, l’elementQualifier est paramétré à ElementNameAndAt-

tous les éléments et attributs présents dans les documents tout en autorisant la simila- rité entre les documents (l’ordre entre les éléments frères et soeurs n’a pas d’importance). Dans un premier temps cette méthode vérifie que les noeuds XML sont comparables entre eux via les méthodes compareNode() et compareNodeBasics() : ces méthodes vont comparer le type du noeud issu du flux de référence et le type du noeud provenant du flux de test. Ceci permet de garantir que l’on compare des éléments avec des éléments, des attributs avec des attributs, des commentaires avec des commentaires, etc.

compareNodeBasics() va vérifier que le noeud de référence et le noeud de test contiennent

des données de type texte ou CDATA3_.

compareNode() prend en paramètres le noeud XML de référence (control), le noeud

XML à tester (test), l’écouteur (listener) l’interface elementQualifier. Cette méthode va vérifier les types des noeuds. Les valeurs des types de noeuds utilisés dans XMLUnit suivent la recommandation du W3C [Le Hors et al., 2004].

Ensuite, si les types sont identiques, la méthode ad hoc va être appelée pour effectuer la comparaison sur ces noeuds (nom et valeur des éléments et attributs) :

• compareElement(control, test, listener) dans le cas de deux noeuds de type Ele-

ment,

• compareText(control, test, listener) dans le cas de deux noeuds de type Text ou

CDATASection,

• compareComment(control, test, listener) dans le cas de deux noeuds de type

Comment (commentaire),

• compareDocumentType(control, test, listener) dans le cas de deux noeuds de type

DocumentType (interface pour les entités définies dans le document XML),

• compareProcessingInstruction(control, test, listener) dans le cas de deux noeuds de type ProcessingInstruction (instruction de traitement),

• compareDocument(control, test, listener) dans le cas de deux noeuds de type

Document (document complet, i.e. le nœud racine de l’arborescence DOM),

Ensuite, la méthode compareNode() vérifie si les noeuds ont éventuellement des enfants : si c’est le cas, la méthode s’appelle elle-même pour comparer les noeuds enfants entre eux. Dans les autres cas de types de noeuds, la comparaison n’est pas effectuée car XM- LUnit n’implémente pas les méthodes correspondantes. Cette limite technique n’affecte pas le bon déroulement de la comparaison dans le cadre de nos travaux étant donné la structure de nos fichiers XML de modèles de situation qui ne contiennent que des 3. CDATA signifie Character Data. Il s’agit d’un balisage particulier qui permet de définir une section dont le contenu ne sera pas analysé par le compilateur XML lors de la lecture du fichier. Le texte sera donc affiché tel qu’il est écrit dans cette section. Ce type de section est très utile si l’on doit utiliser beaucoup de caractères réservés —&, >, <, etc.— et que l’on souhaite réduire l’écriture répétitive des échappements de ces caractères

éléments ayant éventuellement des éléments fils et des attributs.