Faire tourner XSpec en intégration continue

Une suite XSpec qui tourne sur un poste de développement protège la personne qui la lance. En intégration continue, elle protège tout le monde — à condition que la chaîne sache s'arrêter.

XSpec rend deux choses : un rapport HTML lisible, et un code de sortie. 🔴 Le second est le seul que la chaîne regarde, et c'est celui qu'on oublie de vérifier.

Le code de sortie avant le rapport

xspec.sh -s facture.xspec
echo "code de sortie : $?"

Un rapport rouge que personne n'ouvre ne protège de rien. La seule chose qui arrête une chaîne, c'est un code de sortie non nul — le vérifier une fois, à la main, sur un scénario volontairement faux, prend une minute et se fait une seule fois dans la vie d'un projet.

Le piège du test qui ne s'exécute jamais

⚠️ Un chemin de fichier faux, un motif qui ne correspond à rien, et la commande rend 0 : zéro scénario exécuté, zéro échec, chaîne verte.

🔴 C'est le mode de défaillance le plus coûteux, parce qu'il donne exactement le signal attendu. Une chaîne rouge se remarque en dix secondes ; une chaîne verte qui ne teste rien peut tenir des mois, et elle tient d'autant plus longtemps que l'équipe lui fait confiance.

La parade ne porte pas sur les échecs, elle porte sur le compte :

fichiers=$(find test -name '*.xspec')
[ -n "$fichiers" ] || { echo "aucun fichier XSpec trouvé" >&2; exit 1; }

for f in $fichiers; do
  xspec.sh -s "$f" || echec=1
done
[ -z "$echec" ] || exit 1

Deux gardes, deux causes différentes : le premier attrape le motif qui ne correspond à rien, le second empêche la boucle d'avaler un échec.

⚠️ La boucle qui avale le code de sortie

C'est le second garde qui surprend. Le statut d'une boucle for est celui de sa dernière itération : si le troisième fichier sur cinq échoue et que les deux suivants passent, la boucle rend 0 et la chaîne reste verte.

⚠️ L'échec n'est pas ignoré, il est écrasé — et il apparaît bien dans le journal, ce qui rend la chose encore plus difficile à voir : la trace contient le mot « failed », et le résultat est vert.

Publier le rapport, surtout quand ça échoue

Le rapport HTML n'a d'intérêt que dans le cas rouge. ⚠️ Or la plupart des configurations d'intégration s'arrêtent à la première étape en échec, et l'étape qui publie l'artefact vient après : le seul rapport qu'on n'obtient jamais est celui dont on a besoin.

La publication doit donc être déclarée comme s'exécutant quelle que soit l'issue des étapes précédentes. C'est une ligne de configuration, et c'est ce qui fait la différence entre « le test a échoué » et « voici pourquoi ».

L'édition du processeur compte ici aussi

⚠️ XSpec s'appuie sur Saxon. Une chaîne d'intégration qui installe une édition différente de celle du poste de développement peut échouer sur xsl:import-schema ou sur un appel de fonction Java, alors que la feuille n'a pas changé — les quatre limites qui se manifestent ainsi sont décrites dans Saxon HE, PE, EE : ce que l'édition change.

Épingler la version et l'édition dans la configuration de la chaîne coûte une ligne et supprime toute une classe de rouges inexplicables.

Ce que cet article ne couvre pas

• l'écriture des scénarios, décrite dans XSpec en pratique et tester une règle XSLT isolée ;
• l'hébergement des rapports, qui dépend entièrement de votre chaîne ;
• les tests instables, dont la cause est presque toujours une donnée datée ou un ordre non déterminé, jamais l'outil.

⚠️ L'application n'a pas de mode sans interface graphique. En intégration continue, ce sont les lanceurs d'XSpec eux-mêmes qui jouent les scénarios — le débogueur sert à comprendre un échec, pas à le déclencher.

Le chapitre valider et comparer du manuel décrit l'exécution des scénarios depuis l'interface, et la lecture d'un échec une fois qu'il est là.