Tests übersichtlich halten
Ein Label wie Test 17 hilft wenig, wenn der Test fehlschlägt. Column 703 is AAA sagt dagegen sofort, was erwartet wird. Mit aussagekräftigen Namen für Szenarien und Dateien bleibt auch eine größere Testsammlung lesbar.
Nicht jeder Test braucht eine eigene Datei. Wiederkehrende Erwartungen lassen sich aber auslagern, wenn sie wirklich für mehrere Fälle gelten. Das folgende Beispiel zeigt beides: einen konkreten erwarteten Wert und gemeinsam genutzte Prüfungen.
Gemeinsame Erwartungen wiederverwenden
Unsere Funktion vereinheitlicht ein Label: Sie normalisiert die Leerzeichen und wandelt den Text in Großbuchstaben um. Der Test verwendet eine Variable für die Eingabe und importiert zusätzliche Erwartungen:
examples/08-organization/labels.xspec
<?xml version="1.0" encoding="UTF-8"?>
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec"
xmlns:f="urn:example:labels" stylesheet="labels.xsl">
<x:import href="shared.xspec"/>
<x:scenario label="Normalize an editorial label">
<x:variable name="input" select="' xml publishing '"/>
<x:call function="f:label"><x:param select="$input"/></x:call>
<x:expect label="Normalize internal whitespace" select="'XML PUBLISHING'"/>
<x:like label="A non-empty uppercase string"/>
</x:scenario>
</x:description>Die gemeinsam genutzten Erwartungen stehen in dieser Datei:
examples/08-organization/shared.xspec
<?xml version="1.0" encoding="UTF-8"?>
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec"
xmlns:xs="http://www.w3.org/2001/XMLSchema" stylesheet="labels.xsl">
<x:scenario label="A non-empty uppercase string" shared="yes">
<x:expect label="Return a non-empty string" result-type="xs:string"
test="string-length($x:result) gt 0"/>
<x:expect label="Use uppercase characters" result-type="xs:string"
test="$x:result eq upper-case($x:result)"/>
</x:scenario>
</x:description>Mit x:import wird die Datei eingebunden. Ein gemeinsames Szenario wird mit x:like an der passenden Stelle verwendet. Der konkrete Vergleich mit XML PUBLISHING prüft das genaue Ergebnis. Die gemeinsamen Prüfungen verlangen zusätzlich einen nichtleeren String in Großschreibung.
Eine allgemeine Prüfung wie "Es gibt irgendein Ergebnis" wäre hier zu wenig. Gemeinsame Tests sollen die konkrete Erwartung ergänzen, nicht ersetzen. Und wenn zwei Funktionen Leerzeichen unterschiedlich behandeln sollen, passt nicht derselbe Normalisierungstest für beide.
Auch verschachtelte Szenarien können gemeinsame Vorbereitung nutzen. Dabei muss erkennbar bleiben, welche Parameter aus dem äußeren Szenario kommen und welche innen geändert werden. Der fertige Aufruf sollte beim Lesen noch verständlich sein.
Bei der Fehlersuche nur einen Teil ausführen
Mit focus lässt sich ein Szenario in den Mittelpunkt stellen; andere werden dann zurückgestellt. pending kennzeichnet einen Test, der vorerst nicht ausgeführt werden soll. Beides kann während der Entwicklung nützlich sein.
examples/08-organization/focus-pending.demo.xspec
<?xml version="1.0" encoding="UTF-8"?>
<!-- Development-only illustration. Never part of the release test set. -->
<x:description xmlns:x="http://www.jenitennison.com/xslt/xspec"
xmlns:f="urn:example:labels" stylesheet="labels.xsl">
<x:scenario label="Inspect one scenario" focus="Debugging this scenario">
<x:call function="f:label"><x:param select="'xml'"/></x:call>
<x:expect label="Uppercase the label" select="'XML'"/>
</x:scenario>
<x:scenario label="Document a future requirement" pending="Awaiting editorial decision">
<x:call function="f:label"><x:param select="'xml'"/></x:call>
<x:expect label="The future contract is not implemented" select="'XML!'"/>
</x:scenario>
</x:description>Diese Datei ist als Demo gedacht. Sonst könnte ein grüner Bericht entstehen, obwohl ein großer Teil der Tests gar nicht gelaufen ist.
Der Paket-Runner sucht deshalb in den ausgewählten Tests und ihren Imports nach focus und pending. Bleibt so eine Markierung versehentlich stehen, wird die Freigabeprüfung blockiert. Auch im Ergebnis dürfen keine ausstehenden Tests übrig sein. Die absichtlich fehlerhafte Initialen-Variante wird nicht versteckt, sondern separat ausgeführt.
Erwartete Ergebnisse nicht einfach passend machen
Nach einer Änderung am Stylesheet scheitert ein Test. Die erwartete Datei an die neue Ausgabe anzupassen, ist zwar schnell erledigt. Vorher muss aber klar sein: Ist das neue Ergebnis wirklich gewollt, oder ist gerade ein Fehler entstanden?
Ändert sich die Anforderung, darf sich auch das erwartete Ergebnis ändern. Der Grund sollte bei der Änderung dokumentiert werden. Bleibt die Anforderung gleich, muss in der Regel der Code korrigiert werden.
Bei großen Publishing-Dokumenten hilft eine Mischung aus wenigen vollständigen Referenzdateien und vielen kleinen, gezielten Beispielen. Dann wird eine einzelne fehlende Hervorhebung nicht zwischen Hunderten anderer Änderungen übersehen.