XProc-Schritte testen

Bei einem Publishing-Workflow arbeiten oft mehrere Schritte zusammen: Dateien einlesen, XML umwandeln, Metadaten ergänzen und ein Paket erzeugen. XProc kann solche Abläufe verbinden. Seit der 4.0-Reihe lassen sich mit XSpec auch eigene XProc-3-Schritte testen.

Hier prüfen wir einen XProc-Schritt selbst. Das ist etwas anderes, als XProc nur zum Starten von Tests für andere Sprachen zu verwenden. Unser Beispiel bleibt klein: Ein XML-Dokument bekommt ein zusätzliches Wrapper-Element.

Einen Schritt mit einer Option vorbereiten

Der Schritt erhält ein Dokument über seinen Eingangsport und liefert das eingeschlossene Dokument am Ausgang. Ohne weitere Angabe heißt das neue Element package. Mit einer Option lässt sich ein anderer Name wählen.

examples/07-xproc/wrap.xpl

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:ex="urn:example:pipeline" version="3.0" type="ex:wrap" name="wrap">
  <p:input port="source" primary="true" content-types="application/xml"/>
  <p:output port="result" primary="true"/>
  <p:option name="wrapper" as="xs:QName" select="QName('', 'package')"/>
  <p:wrap-sequence wrapper="{$wrapper}"/>
</p:declare-step>

type="ex:wrap" gibt dem Schritt den Typnamen, über den er aufgerufen wird. Die XSpec-Datei verweist mit xproc auf die Definition. x:call benennt mit step den Schritt, x:input liefert die Eingabe und x:option setzt die Option. Mit port wird der Ausgang für den Vergleich ausgewählt.

examples/07-xproc/wrap.xspec

<?xml version="1.0" encoding="UTF-8"?>
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec"
  xmlns:ex="urn:example:pipeline" xproc="wrap.xpl">
  <x:scenario label="Use the default wrapper">
    <x:call step="ex:wrap">
      <x:input port="source"><article><title>XML Testing</title></article></x:input>
    </x:call>
    <x:expect label="Return a package" port="result">
      <package><article><title>XML Testing</title></article></package>
    </x:expect>
  </x:scenario>
  <x:scenario label="Use a custom wrapper">
    <x:call step="ex:wrap">
      <x:input port="source"><article><title>XML Testing</title></article></x:input>
      <x:option name="wrapper" select="QName('', 'publication')"/>
    </x:call>
    <x:expect label="Return a publication" port="result">
      <publication><article><title>XML Testing</title></article></publication>
    </x:expect>
  </x:scenario>
</x:description>

Der erste Test verwendet den Standardwert package, der zweite den Namen publication. Die Option wird als QName übergeben. Beide Varianten sind wichtig: Nur mit dem Standardtest würde nicht auffallen, wenn die Option ignoriert wird. Nur mit dem Sonderfall bliebe ein falscher Standardwert unentdeckt.

XML Calabash bereitstellen

Saxon allein reicht für dieses Beispiel nicht aus. Zusätzlich wird eine passende XML-Calabash-3-Distribution benötigt. Die XSpec-Release-Dokumentation zu 4.0.2 nennt XML Calabash 3.0.47 als getestete Kombination. Der lokale Lauf muss trotzdem mit der tatsächlich installierten Version geprüft und protokolliert werden.

Installiert wird die vollständige Distribution mit ihren Bibliotheken, nicht nur eine einzelne JAR-Datei. Für die XProc-Tests muss XSpec den Calabash-Klassenpfad verwenden.

Der Paket-Runner liest diesen aus CALABASH_CP. Die Pfade im folgenden Beispiel müssen an die eigene Installation angepasst werden:

export CALABASH_CP="/path/to/xmlcalabash/xmlcalabash-app.jar:/path/to/xmlcalabash/lib/*"
python scripts/run-tests.py --only xproc

Unter PowerShell wird der Klassenpfad mit einem Semikolon getrennt:

$env:CALABASH_CP = 'C:\tools\xmlcalabash\xmlcalabash-app.jar;C:\tools\xmlcalabash\lib\*'
python scripts/run-tests.py --only xproc

Der genaue Name der Anwendungs-JAR hängt von der installierten Distribution ab. Der Runner übergibt den Calabash-Klassenpfad für diesen Lauf als SAXON_CP. Beim direkten XSpec-Aufruf wird der Modus -p verwendet. Fehlt die Laufzeit, blockiert das Paket die XProc-Suite, statt sie einfach als bestanden zu markieren.

Vom kleinen Schritt zum ganzen Workflow

Der Wrapper prüft Eingabe, Ausgabe und Option. Er greift absichtlich weder aufs Netzwerk zu noch schreibt er Dateien. So bleibt leicht erkennbar, was der Test zeigen soll.

Bei einer echten Produktionspipeline kommen weitere Fragen hinzu: Sind alle Dateien erreichbar? Darf der Prozess in den Ausgabeordner schreiben? Was passiert, wenn ein externer Dienst ausfällt? Dafür braucht es zusätzliche Tests mit passenden Dateien und Testdiensten. Ein grüner Test für den Wrapper beantwortet diese Fragen nicht.

<< zurück

vor >>