Tests regelmäßig ausführen und Beispiele herunterladen

Der erste Test ist schnell geschrieben. Den größten Nutzen bringt er aber, wenn er nach jeder relevanten Änderung wieder läuft. Dafür enthält das Paket Startskripte, Berichte und eine Zusammenfassung des Teststands.

Die alten Schulungsdateien liegen getrennt von den neuen Beispielen. Ihre HTML-Berichte zeigen, wie damals getestet wurde. Sie sind keine Ergebnisse der heutigen Testumgebung.

Alle Tests mit einem Aufruf starten

Dieser Befehl startet die acht Basissuiten:

Für den vollständigen Durchlauf kommen die XProc-Suite und die absichtlich fehlerhafte Initialen-Variante hinzu. Dafür muss die XProc-Laufzeit vorher eingerichtet sein:

Die normalen Tests sollen ohne Fehler und ohne ausstehende Erwartungen durchlaufen. Bei der fehlerhaften Variante werden dagegen genau die zwei vorgesehenen Abweichungen erwartet. Ein beliebiger Programmabbruch genügt nicht.

Die HTML-Berichte eignen sich zum Lesen, die JUnit-Dateien für die automatische Auswertung auf einem Build-Server. scripts/ci.sh zeigt einen Einstieg, der in die eigene CI-Umgebung eingebaut werden kann. Eine fertig eingerichtete GitHub-, GitLab- oder Jenkins-Installation ist damit noch nicht verbunden.

Welche Teile des Stylesheets werden erreicht?

Ein Coverage-Bericht zeigt, welche Teile eines XSLT-Stylesheets beim Testen ausgeführt wurden. So lassen sich zum Beispiel Zweige finden, für die noch ein Testfall fehlt. Für diese XSpec-Funktion nennt die Dokumentation Saxon ab Version 12.4 als Voraussetzung. Sie ist eine XSLT-Funktion und nicht automatisch für alle hier vorgestellten Sprachen verfügbar.

Der Runner startet dafür einen zusätzlichen Lauf, getrennt von der JUnit-Ausgabe. Die möglichen Berichtskombinationen richten sich nach dem verwendeten XSpec-Launcher.

Eine hohe Abdeckung bedeutet nicht, dass alle Ergebnisse richtig sind. Eine Funktion kann ausgeführt werden und trotzdem einen falschen Wert liefern. Dafür braucht der Test eine passende Erwartung. Auch unbekannte Coverage-Einstufungen sollten genauer angesehen werden.

Und ein Vergleich von XML-Bäumen sagt noch nichts darüber aus, wie die Ausgabe im Browser oder als PDF aussieht. Layout, Serialisierung und externe Dienste brauchen eigene Prüfungen. Für spezielle Aufrufe außerhalb des normalen Importmodells bietet XSpec außerdem Tests mit externen Transformationen.

Was steckt im Download?

Das Beispielprojekt enthält englische Quelltexte, Eingabe- und Erwartungsdateien, XSpec-Suiten und Startskripte. Beide Sprachfassungen verwenden dieselben Beispiele. Die Statusdatei STATUS.json und die Berichte zeigen, welche Prüfungen bereits gelaufen sind.

Im aktuellen Entwurf sind alle 46 XML-bezogenen Beispieldateien auf Wohlgeformtheit geprüft, einschließlich der erzeugten individuellen Spaltensuite. Alle 16.384 Spaltenreferenzen stimmen mit der unabhängigen Python-Berechnung überein. Die zehn korrigierten Initialen-Beispiele wurden direkt mit libxslt erfolgreich ausgeführt; bei der fehlerhaften Variante wurden die zwei erwarteten Abweichungen erkannt.

Zusätzlich wurden XSpec 4.0.3, Saxon-HE 12.9 und Java 21.0.10 verwendet, um die XSLT-, XQuery- und Schematron-Suiten auszuführen. Acht positive Kernsuiten bestanden mit 56 Assertions. Die absichtlich fehlerhafte Initialen-Suite zeigte genau die erwarteten zwei Fehlschläge bei drei Assertions. Der kompakte Vollbereichstest prüfte alle 16.384 Spaltenwerte in einer Assertion; der individuell generierte Bereich 695 bis 710 wurde danach mit 16 eigenen Assertions ausgeführt.

Die XProc-Suite ist weiterhin offen, weil in der Prüfumgebung keine vollständige XML-Calabash-3-Installation mit CALABASH_CP verfügbar war. Deshalb ist das Beispiel-ZIP weiterhin als DRAFT gekennzeichnet. Die direkten libxslt-Prüfungen werden getrennt von den XSpec-Nachweisen ausgewiesen.

Download der Beispieldateien

Im Download-Ordner finden Sie alle Beispieldateien zu diesem Artikel.