Testen und Fehler suchen

(Auszug aus "XSLT Kochbuch" von Sal Mangano)

"Nach einem Absturz kommt oft eine Meldung der Art »ID 02«.
Dabei steht »ID« für Eigentümlichkeit (engl. Idiosyncrasy)
und die Zahl dahinter für die Anzahl der Monate,
die dieses Produkt noch hätte getestet werden müssen."

Guy Kawasaki

Einleitung

Viele der XSLT-Skripte, die Sie schreiben, um eine wohldefinierte Eingabe zu transformieren, werden Sie nur einmal benötigen. Dann besteht das Testen aus wenig mehr als der Ausführung der Transformation auf der Eingabe und einer Überprüfung der Ausgabe. Aber auch in diesem einfachen Fall sollten Sie sich fragen, wie Sie am besten mit einem Stylesheet umgehen, wenn es nicht das macht, was Sie erwarten? Normalerweise finden sich die verantwortlichen Zeilen mit einem einfachen Blick in den Code. Für Entwickler, die aber mit XSLT noch wenig vertraut sind, ist die Fehlersuche (engl. debugging) in Form einer Code-Inspektion oftmals nicht besonders effektiv – das gilt auch für jene mit mehr Erfahrung bei der Manipulation von XML mit prozeduralen Sprachen. Daher stellt dieses Kapitel grundlegende Debugging-Techniken vor, die Ihnen eine schnellere Lösung für häufige Kodierungsfehler zeigen und Ihre XSLT-Kenntnisse vertiefen sollen.

In diesem Buch wird in vielen Beispielen betont, wie wichtig es ist, wiederverwendbares XSLT zu schreiben. Ein Autor, der wiederverwendbaren Code schreiben will, muss diesen einer umfangreicheren Testprozedur unterziehen. Wiederverwendbarer Code wird per definitionem oftmals in einer Umgebung eingesetzt, über die der Autor nur wenig wissen kann. Daher sollten Sie sicherstellen, dass sich der Code bei typischen Eingaben und unter Randbedingungen so verhält, wie Sie es angekündigt haben. Außerdem sollte wirklich wiederverwendbarer Code sich auch dann auf vorhersehbare Weise verhalten, wenn er es mit ungültigen Eingaben zu tun hat.

Entwickler testen ihren Code umso eher, je leichter das Testen ist. Interpretierte Sprachen wie XSLT sind normalerweise leichter zu testen, weil kein Compile- und Link-Zyklus damit verbunden ist. XSLT hat noch den weiteren Vorteil, dass die Syntax der Sprache und ihrer Daten identisch ist (engl. homoiconic). Dank dieser Eigenschaft können Testdaten sehr leicht ins Stylesheet eingebettet werden, wodurch vollständig abgeschlossene Tests entstehen.

Alle Rezepte in diesem Kapitel basieren allein auf den Möglichkeiten von XSLT. Allerdings gibt es nichts, was einen echten Debugger schlagen könnte. Daher folgt eine Liste kommerzieller Produkte in diesem Bereich. Ich habe sie nicht alle ausprobiert, d.h., Sie sollten die Produkte auf dieser Liste nicht als Empfehlung verstehen. Viele davon können weit mehr als nur XSLT debuggen:

  • Active States Visual XSLT 2.0
  • Altovas XML Spy Version 2005
  • Emacs-basierter XSLT-Debugger: XSLT-process
  • Exchanger
  • MarrowSofts Xselerator 2.6
  • oxygen
  • Stylus Studio 6
  • WebSphere Studio Application Developer

Treebeard ist ein Open Source-Projekt, das in Java geschrieben ist und mit den XSLT-Prozessoren in Xalan, Saxon, jd und Oracle funktioniert. Es ist mehr eine Art visuelle XSLT-Entwicklungsumgebung als ein ausgewachsener Debugger, kann aber bei der Fehlersuche in XPath-Ausdrücken hilfreich sein.

  

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XSLT bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2006 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XSLT Kochbuch" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O'Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de