Page 1
Die
T
E
Xnische
K
omödie
DANTE
Deutschsprachige
Anwendervereinigung TEX e.V.
Gerd Neugebauer: Minimal? – Vom Testen eines Text-
satzsystems, Die TEXnische Komödie 3-2006, S. 34-43.
Reproduktion oder Nutzung dieses Beitrags durch konventionelle, elek-
tronische oder beliebige andere Verfahren ist nur im nicht-kommerziellen
Rahmen gestattet. Verwendungen in größerem Umfang bitte zur Infor-
mation bei DANTE e.V. melden. Für kommerzielle Nutzung ist die Zu-
stimmung der Autoren einzuholen.
Die TEXnische Komödie ist die Mitgliedszeitschrift von DANTE,
Deutschsprachige Anwendervereinigung TEX e.V. Einzelne Hefte können
von Mitgliedern bei der Geschäftsstelle von DANTE, Deutschsprachi-
ge Anwendervereinigung TEX e.V. erworben werden. Mitglieder erhalten
Die TEXnische Komödie im Rahmen ihrer Mitgliedschaft.
Page 2
Minimal? – Vom Testen eines Textsatzsystems
Gerd Neugebauer
Ein System wie εXTEX muss getestet werden. Dabei kommt die Kunst der
Minimalbeispiele zum Einsatz. Diese treten hier in der Form von Testfäl-
len auf. εXTEX soll durch Testfälle so abgesichert werden, dass während der
Weiterentwicklung keine ungewollten Veränderungen an den implementier-
ten Funktionalitäten auftreten.
Einleitung
In Mailing-Listen wie tex-d-l und News-Gruppen wie de.comp.text.tex wird
auf Fragen immer wieder mit einem Hinweis auf ein Minimalbeispiel geant-
wortet. Ein Minimalbeispiel dient dabei dazu, die Essenz des Effekts, den
man zeigen will, herauszuarbeiten. Das hilft auf der einen Seite zu verstehen,
welche Elemente daran beteiligt sind – wenn man noch etwas weglassen kann,
ist es noch nicht minimal. Auf der anderen Seite erlaubt es anderen Anwen-
dern, den Effekt zu reproduzieren. Damit kann nachgewiesen werden, dass
der Effekt immer noch auftritt, auch wenn ein anderes TEX-System benutzt
wird.
Das Konzept des Minimalbeispiels ist auch noch an anderer Stelle relevant,
nämlich in der Software-Entwicklung. Hier kommt es in der Form von Test-
fällen vor. Eine Software sollte normalerweise eine Reihe von Anforderungen
erfüllen. Um dies zu testen, werden die Anforderungen in Testfälle gegossen.
Damit hat man eine – im besten Fall – große Liste von Testfällen, die es
gestattet detailliert abzuschätzen, in welchem Maß die Anforderungen erfüllt
sind.
Im Gegensatz dazu steht ein einzelner großer Testfall. Entweder er geht durch,
oder er geht eben nicht durch. Hier ist eine detaillierte Bewertung schwieriger.
Auch ist es schwieriger, einen Fehler zu lokalisieren und gegebenenfalls zu
beheben.
Während der Entwicklung können Testfälle dabei helfen, das Funktionieren
von Code zu beurteilen. Oftmals wird Code geändert – sei es, dass er um
neue Funktionalität erweitert wird, oder sei es, dass er verbessert wird. Das
wird heute oft als Refactoring bezeichnet [3]. Zum Extrem wird dies beim
Die TEXnische Komödie 3-2006 – Nachdruck
Page 3
Minimal? – Vom Testen eines Textsatzsystems
35
Test-Driven Development getrieben [1, 6]. Hier werden als erstes die Testfälle
erstellt und danach die Software implementiert.
In NT S wurde im Gegensatz zu dem bisher Gesagten im Wesentlichen ein
großer Testfall benutzt – das TEX Book [5]. Das zeigt zwar viele Eigenschaften
von TEX, aber eben nicht alle. Und wenn dann ein Fehler auftritt, kann man
nur schwer beurteilen, wie schwerwiegend er ist.
Auch der Trip-Test von TEX testet einige Eigenschaften ab. Dies betrifft vor
allem das Verhalten von TEX in Randbereichen des Einsatzes. Es ist denkbar,
ein relativ einfaches Programm zu schreiben, das den Trip-Test bestehen
würde, aber damit noch bei weitem nicht geeignet, damit Texte zu setzen.
Auf der anderen Seite werden im Trip-Test auch Eigenschaften abgetestet,
die für ein TEX-kompatibles System nicht relevant sind.
εXTEX (http://www.extex-project.org) hat als ein Ziel, in einem Kompatibilitäts-
modus die gleiche Funktionalität wie TEX anzubieten. Deshalb ist es sinnvoll,
hier eine Test-Suite aufzubauen, die sowohl die Kompatibilität sicherstellt,
wie auch die Stabilität des bereits erstellten Codes überprüft.
Hyphenation – ein Beispiel
Um das Testen etwas anschaulicher zu gestalten, betrachten wir ein Beispiel
aus dem Bereich der Silbentrennung.
Testfälle entstehen aus Anforderungen. Anforderungen an TEX finden sich in
[4, 5]. Also liest man, was dort steht und versucht, sich etwas auszudenken,
wie es überprüft werden kann. Selbst ohne allzu große Kenntnisse in TEX
kann man auf diese Weise Schritt für Schritt die Anforderungen erfassen und
in Testfälle übersetzen.
Beipielsweise findet sich in [4] die folgende Aussage:1
902. TEX will never insert a hyphen that has fewer than
\lefthyphenmin letters before it or fewer than \righthyphenmin
after it; hence, a short word has comparatively little chance of being
hyphenated.
1 Übersetzung: TEX wird keine Trennstelle einfügen, die weniger als \lefthyphenmin Buch-
staben davor oder weniger als \righthyphenmin danach hat; damit hat ein kurzes Wort
eine relativ geringe Chance, getrennt zu werden.
Die TEXnische Komödie 3-2006 – Nachdruck
Page 4
36
Minimal? – Vom Testen eines Textsatzsystems
Die Silbentrennung in TEX wird dann benutzt, wenn der aktuelle Absatz
nicht ohne Trennstellen „gut“ umbrochen werden kann. In diesem Fall werden
zusätzliche, optionale Trennstellen eingefügt. Dazu gibt es einen Algorithmus,
der aus \pattern{} gespeist wird. Zusätzlich gibt es noch die Ausnahmen,
die über \hyphenation{} eingegeben werden.
Für den ersten Testfall wollen wir uns auf die Werte aus \hyphenation kon-
zentrieren. Gilt die Aussage auch für diese oder nur für die Muster-basierten
Trennstellen?
Um das zu überprüfen, brauchen wir ein Minimalbeispiel. Da wir wirklich
minimalistisch arbeiten wollen, nutzen wir zuerst einmal nur iniTEX. Dies
ist der eigentliche Programmkern, ohne dass irgendwelche Definitionen aus
Formaten gelesen werden.
Damit müssen wir uns um fast alles auch wirklich selbst kümmern. Das fängt
damit an, dass die Klammern noch nicht als solche behandelt werden – die
Kategorien müssen erst mit \catcode eingestellt werden. Auch gibt es noch
keinen Font. Also laden wir cmr10 und benutzen ihn im Folgenden. Für die-
sen Font stellen wir auch noch den Hyphen-Charakter ein. Der Wert ist der
ASCII-Code des Zeichens, das bei der Trennung eingefügt werden soll. Der
Wert 45 ist dabei der Code für das Zeichen „-“. Das führt zu folgenden Zeilen
Code:
\catcode‘{=1
\catcode‘}=2
\font\f cmr10 \f
\hyphenchar\f=45
Jetzt können wir mit dem eigentlichen Test beginnen. Wir wollen einem Wort
mit \hyphenation eine Trennstelle zuweisen. Da es nicht relevant ist, wel-
ches Wort wir nehmen, haben wir uns für abcdef entschieden, das in der
Mitte trennbar sein soll. Damit auch getrennt werden muss, stellen wir die
Seitengröße auf eine Breite von 25 Punkten und eine Höhe von 100 Punkten.
Schließlich setzen wir noch \lefthyphenmin und \righthyphenmin jeweils
auf 0, damit auch wirklich getrennt werden kann.
\hyphenation{abc-def}
\hsize=25pt
\vsize=100pt
\lefthyphenmin=0
\righthyphenmin=0
Die TEXnische Komödie 3-2006 – Nachdruck
Page 5
Minimal? – Vom Testen eines Textsatzsystems
37
Um die Breite zu sehen, zeichnen wir mit \hrule eine Linie der Textbreite
und können nun unser Wort „abcdef“ ausgeben. Mit \end schließen wir die
Verarbeitung ab.
\hrule width \hsize height 1pt
abcdef
\end
Wenn wir die obigen Zeilen in einer Datei htest.tex haben, können wir auch
schon ansehen, was TEX daraus macht:
initex htest.tex
Im Preview sehen wir dann in etwa das Folgende – allerdings ohne den Rah-
men:
abcdef
Das Wort wurde nicht getrennt, obwohl wir das erwartet hatten. Irgend et-
was stimmt da nicht. Vielleicht wird die Regel doch nicht auf Worte aus
\hyphenation angewendet?
Doch halt: Da war doch noch etwas. TEX trennt niemals das erste Wort eines
Absatzes. Also müssen wir dafür sorgen, dass unser Wort nicht das erste ist.
Dazu schreiben wir einfach ein x davor:
x abcdef
Damit erhalten wir:
x
abc-
def
Genau das ist der erwartete Effekt. Also haben wir unser Minimalbeispiel
erreicht. Daraus können wir noch einige weitere Testfälle ableiten, indem wir
\lefthyphenmin und \righthyphenmin variieren oder den Bindestrich nach
links oder rechts verschieben.
Die TEXnische Komödie 3-2006 – Nachdruck
Page 6
38
Minimal? – Vom Testen eines Textsatzsystems
Dann ergibt beispielsweise der folgende Code das Ergebnis, dass keine Tren-
nung stattfindet:
\lefthyphenmin=4
\righthyphenmin=4
Das sieht dann folgendermaßen aus:
x
abcdef
Die Test-Umgebung
Die Test-Suite von εXTEX hat das Ziel, die Testfälle automatisiert ablaufen
lassen zu können. Damit wird es möglich, ohne menschlichen Eingriff feststel-
len zu können, in welchem Maß die Anforderungen schon erfüllt sind. Und
schließlich ist es bei einer größeren Anzahl von Testfällen aufwändig, jedes
Mal im Preview ein Ergebnis zu überprüfen.
εXTEX wird in Java entwickelt. Damit liegt es nahe, die Werkzeuge aus der
Java-Welt einzusetzen. Als ein Standard-Werkzeug für Unit-Tests hat sich
hier JUnit [2] durchgesetzt. JUnit ist im Kern recht einfach – sowohl was
die dahinter liegenden Konzepte als auch, was die Anwendung betrifft. Jeder
Testfall ist eine Java-Methode; die umschließende Java-Klasse stellt eine Test-
Suite dar.
Damit das funktioniert, muss die Klasse von einer Basisklasse abgeleitet sein
und die Methoden müssen einer Namenskonvention genügen. Die Basisklasse
ist junit.framework.TestCase, und der Klassenname muss mit „Test“ en-
den. Die Konvention sagt, dass die Methoden public void sein müssen und
mit der Zeichenkette „test“ beginnen.
In den Testfall-Methoden sollte dann auf einige der vielen „assert“-Methoden
der Basis-Klasse zurückgegriffen werden. Diese dienen sowohl dazu, Nachbe-
dingungen zu überprüfen, als auch, dem Test-Framework Erfolg oder Miss-
erfolg zu signalisieren. Das sieht beispielsweise folgendermaßen aus:
public class MyTest extends TestCase {
public MyTest(final String name) {
Die TEXnische Komödie 3-2006 – Nachdruck
Page 7
Minimal? – Vom Testen eines Textsatzsystems
39
super(name);
}
public void test1() throws Exception {
// Perform tests here
assertEquals(2, 1 + 1);
}
}
So viel als kurzer Ausflug in die „Tiefen“ von Java. Testfälle kann man aber
auch erstellen und laufen lassen, wenn man kein Java kennt und nur die
passenden Werte an die richtigen Stellen schreibt.
Die Aufgabe für εXTEX ist vielfach die gleiche: Der Interpreter wird mit einer
Eingabe gefüttert. Die Ausgabe ist einerseits der Strom der „Nodes“, der zur
Ausgabe geht und der Fehler-Kanal, der am Ende in der Log-Datei landet.
Diese beiden Ströme können abgefangen und mit vorgegebenen Werten ver-
glichen werden. Dafür gibt es die Klasse ExTeXLauncher und die Methode
assertOutput. Dieser Methode gibt man drei Zeichenketten mit:
◦ den Code, der ausgeführt werden soll,
◦ das Ergebnis im Ausgabekanal und
◦ das Ergebnis in der Log-Datei.
Das sieht dann beispielsweise folgendermaßen aus:
public class RelaxTest extends ExTeXLauncher {
public RelaxTest(final String name) {
super(name);
}
public void test1() throws Exception {
assertOutput(
// --- Input code
"\\relax\\end",
// --- Log channel
"",
// --- Output channel
""
);
}
}
Die TEXnische Komödie 3-2006 – Nachdruck
Page 8
40
Minimal? – Vom Testen eines Textsatzsystems
Man muss nur wissen, dass man den Backslash in der Zeichenkette verdoppeln
muss und andere Sonderzeichen durch Voranstellen eines Backslash kenntlich
gemacht werden müssen. Insbesondere der String-Begrenzer (\") und das
Newline-Zeichen (\n) sind zu nennen.
Das war alles. Schon kann man die Tests laufen lassen. Damit alles noch mit
einer netten grafischen Oberfläche versehen wird, genügen die folgenden drei
Zeilen:
public static void main(final String[] args) {
junit.swingui.TestRunner.run(RelaxTest.class);
}
Das Ergebnis sieht dann wie das Beispiel in Abbildung 1 aus. Hier wird an-
gezeigt, wieviele Testfälle enthalten sind und wieviele erfolgreich oder mit
einem Fehler beendet wurden. Der Gesamterfolg wird durch den grünen Bal-
ken signalisiert; anderenfalls wäre er rot. In einem solchen Fall gilt es dann
herauszufinden, wo die Ursache für den Fehlschlag zu suchen sein könnte.
Verschwiegen haben wir bisher, wie man die Tests laufen lassen kann. Und
auch das geht recht einfach. Hierfür ist in εXTEX das Skript develop/junit
vorgesehen. Hier werden alle Einstellungen passend vorgenommen und der
Test wird gestartet:
develop/junit de.dante.extex.interpreter.primitives.RelaxTest
Das funktioniert auf die gleiche Weise sowohl unter Unix wie auch unter Win-
dows. Man muss also kein Unix-affiner Hacker sein, um Testfälle für εXTEX
erstellen und ausführen zu können.
Genauso gut lassen sich die Testfälle aber auch – ohne diese Zusatzzeilen –
aus einer IDE wie Eclipse (http://www.eclipse.org) heraus abarbeiten. Das
ist an dem gleichen Beispiel in Abbildung 2 zu sehen.
Schließlich gibt es auch noch die textbasierte Variante. Eine Ausgabe kann
dann wie in Abbildung 3 aussehen. Diese wird auch benutzt, um alle Testfälle
en bloc abarbeiten zu lassen.
Zusammenfassung und Ausblick
Im Rahmen von εXTEX wurde bisher eine Test-Suite in einer Basis-Version
erstellt. Diese enthält bereits über 7000 Testfälle. Da die Testfälle immer nur
Die TEXnische Komödie 3-2006 – Nachdruck
Page 9
Minimal? – Vom Testen eines Textsatzsystems
41
Abbildung 1: Ein Test-Bericht von JUnit
einen kleinen Aspekt überprüfen, ist zu erwarten, dass es sehr viele davon
geben muss. Eine einigermaßen vollständige Test-Suite wird sicher auf mehr
als die doppelte Größe des bisher Erreichten anwachsen müssen.
Wer sich bisher in der Kunst des Minimalbeispiels auf der Ebene von LATEX
versucht hat, kann sich hier in einem neuen Minimalismus üben. Wegen des
tief gewählten Startpunkts muss man auch nicht viele Pakete kennen. Dafür
muss man sich um einige Dinge kümmern, die sonst schon geregelt sind. Auf
diese Weise kann man sehr einfach tiefe Einblicke in die Arbeitsweise von
TEX – und εXTEX – erhalten.
Für εXTEX wäre es sehr hilfreich, wenn sich der eine oder andere finden würde,
der sich in solchen Minimalbeispielen üben will und die Ergebnisse für εXTEX
beisteuert. Eine Mitarbeit in diesem oder einem anderen Bereich von εXTEX
ist jederzeit willkommen.
Die TEXnische Komödie 3-2006 – Nachdruck
Page 10
42
Minimal? – Vom Testen eines Textsatzsystems
Abbildung 2: JUnit in Eclipse
..........
Time: 10,054
OK (10 tests)
Abbildung 3: JUnit, textbasiert
Die TEXnische Komödie 3-2006 – Nachdruck
Page 11
Minimal? – Vom Testen eines Textsatzsystems
43
Literatur
[1] Kent Beck: Test-Driven Development; Addison-Wesley; Boston, MA;
2003.
[2] Kent Beck: JUnit kurz & gut; O’Reilly; Köln; 2005.
[3] Martin Fowler: Refactoring – Wie Sie das Design vorhandener Software
verbessern; Addison-Wesley; 2000.
[4] Donald E. Knuth: TEX – the Program; Bd. B von Computers and
Typesetting; Addison-Wesley; Boston, MA; 1986.
[5] Donald E. Knuth: The TEXbook; Bd. A von Computers and Typesetting;
Addison-Wesley; Boston, MA; 1996.
[6] Johannes Link: Unit Tests mit Java – der Test-First-Ansatz;
dpunkt.verlag; Heidelberg; 2002.
Die TEXnische Komödie 3-2006 – Nachdruck