Welche Tests lohnen sich im XML-Projekt?
Nicht jedes Projekt braucht gleich Hunderte Tests. Ein guter Anfang ist eine Funktion, die schon einmal Probleme gemacht hat, oder ein Template, das auf keinen Fall kaputtgehen darf. Vor dem ersten Test steht eine einfache Frage: Woran erkennen wir, dass das Ergebnis richtig ist?
Bei einer Konvertierung kann das heißen: Der Text muss vollständig erhalten bleiben, Querverweise müssen weiterhin stimmen und Tabellenzellen dürfen ihre Reihenfolge nicht ändern. Tests helfen sowohl bei neuer Entwicklung als auch bei der Wartung bestehender Stylesheets. Diese Einsatzfälle waren schon der Ausgangspunkt unserer XSpec-Schulung.
Gültiges XML ist noch kein richtiges Ergebnis
Ein Schema kann prüfen, ob die Struktur eines Dokuments zulässig ist. Es sagt aber nicht automatisch, ob eine Transformation den Inhalt richtig verarbeitet hat. Nehmen wir diesen Absatz:
<article>
<title>Publishing with XML</title>
<p>Read the <em>important</em> instructions.</p>
</article>Entfernt das Stylesheet die em-Auszeichnung, kann das Ergebnis immer noch gültiges XML sein. Trotzdem fehlt die Hervorhebung. Ein XSpec-Test kann genau diese Stelle prüfen und die erwartete Auszeichnung verlangen. Bei einem Export als reiner Text wäre das Entfernen dagegen gewollt. Entscheidend ist also das Ziel der Verarbeitung.
Je nach Aufgabe setzen wir den Test an einer anderen Stelle an:
| Was wird getestet? | Was wollen wir wissen? | Beispiel im Paket |
|---|---|---|
| Funktion | Kommt der richtige Wert zurück? | Hexadezimalzahl oder Spaltenname |
| Template | Wird dieser XML-Ausschnitt richtig umgebaut? | Initiale oder Literaturangabe |
| Modul | Stimmen Auswahl und Reihenfolge? | Bücher mit XQuery filtern |
| Schematron-Regel | Wird der richtige Fehler gemeldet? | Leerer Titel oder fehlendes Verweisziel |
| XProc-Schritt | Stimmen Ein- und Ausgabe? | Dokument in ein Wrapper-Element einschließen |
Kleine Tests machen die Fehlersuche leichter. Ein Test für einen kompletten Export zeigt dafür, ob die einzelnen Teile auch zusammenpassen. Beides hat seinen Platz.
Typische Aufgaben im Publishing
Bei einer Migration von einem XML-Format in ein anderes sind IDs, Verweise, Tabellen und die Reihenfolge von Inhalten gute Testkandidaten. In einer gemeinsam genutzten XSLT-Bibliothek lohnen sich Tests für Nummerierung, Dateinamen und Metadaten. Bei kundenspezifischen Anpassungen helfen sie dabei, dass eine neue Sonderregel nicht die Ausgabe eines anderen Kunden verändert.
Besonders einfach ist der Einstieg mit einem bereits gefundenen Fehler. Das betroffene Dokument wird auf die entscheidende Stelle verkleinert. Dazu legen wir das gewünschte Ergebnis ab und schreiben den Test. Erst dann korrigieren wir das Stylesheet. Taucht derselbe Fehler später wieder auf, schlägt der Test an. Genau dafür sind Regressionstests da.
Ganze Dokumente oder einzelne Eigenschaften prüfen?
Bei einem kleinen Absatz ist es oft am einfachsten, das komplette erwartete XML zu hinterlegen. Bei einem großen Dokument kann ein XPath-Ausdruck gezielter sein: Sind alle IDs noch vorhanden? Gibt es genau eine Hauptüberschrift? Zeigen die Verweise auf die richtigen Ziele?
Der Test sollte alles Wichtige erfassen, aber nicht bei jeder unwichtigen Formatierungsänderung scheitern. Ein bloßes „Es kommt etwas heraus“ reicht allerdings nicht, wenn wir eine bestimmte Struktur erwarten.
Neben dem Normalfall gehören ein paar schwierige Eingaben dazu: ein leerer Absatz, ein fehlendes Attribut, ein anderer Namensraum oder der Übergang von Z zu AA. Solche Fälle finden oft mehr Fehler als viele fast identische Beispieldokumente.