5.3. checkerberry cockpit XML-Konverter

Das Ziel bei der Entwicklung von automatisierten Tests besteht in der Erreichung einer möglichst hohen Testabdeckung. Im Fall von checkerberry db gilt dabei: Je höher die Testabdeckung, desto mehr XML-Testdaten werden verwendet. Die hohe Anzahl der Testdaten wird dann problematisch, wenn massive Änderungen an der Datenbankstruktur vorgenommen werden wie z.B. die Umbenennung von Tabellen- und Spaltennamen in der Datenbank. In diesem Fall müssen die entsprechenden Tags und Attribute in den XML-Testdaten ebenfalls angepasst werden.

In der Regel sinkt die Gefahr von umfangreichen Datenbankänderungen mit der Laufzeit des Projektes. Inkonsistenzen in dem Datenbankdesign werden nach und nach erkannt und behoben. In einigen Unternehmen wird das Datenbankdesign jedoch von eigenen Abteilungen geprüft und korrigiert. Dies geschieht nicht immer zeitnah. Im schlimmsten Fall beziehen sich die Änderungen auf weite Teile der Datenbank, sodass ggf. eine große Anzahl von Tabellen- und Spaltennamen umbenannt werden müssen. Somit müssen alle XML-Testdaten, also ggf. mehrere hundert Dateien, aktualisiert werden. Diese Aufgabe ist manuell kaum zu lösen.

Aus diesem Grund stellt das checkerberry test center den XML-Konverter als Teil von checkerberry cockpit zur Verfügung, das die Massenänderung von XML-Testdaten ermöglicht. Über eine einfache Excel-Datei können verschiedene Operationen auf den XML-Testdaten ausgeführt werden. Dazu gehören das Umbenennen von Tabellen- und Spaltennamen, das Hinzufügen von neuen Spalten und das Löschen bestehender Spalten. Darüber hinaus können die gewünschten Migrationsschritte auch manuell im checkerberry cockpit XML-Konverter vorgenommen werden.

Im Folgenden wird die Bedienung des XML-Konverters beschrieben.

5.3.1. Aufgaben

Die Aufgabe des checkerberry cockpit XML-Konverters besteht in der Manipulation von XML-Dateien für Testdaten.

Im Folgenden werden die verschiedenen Änderungsmöglichkeiten anhand der folgenden Beispieldateien beschrieben.

Beispiel 5.1. Testdaten-Beispiel für checkerberry cockpit XML-Konverter

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <USERS SURNAME="Simpson" NAME="Homer" BIRTHDATE="1946-09-16"/>
  <USERS SURNAME="Simpson" NAME="Maggie" BIRTHDATE="2006-09-15"/>
  <SHOP_USERS SURNAME="Smithers" NAME="Waylon" RESERVED=""/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery" RESERVED=""/>
</dataset>


Die Testdaten enthalten zwei Tabellen (USERS und SHOP_USERS) mit jeweils zwei Einträgen, die in den folgenden Abschnitten manipuliert werden.

5.3.1.1. Tags umbenennen

Die Tags in den XML-Testdaten entsprechen den Tabellennamen innerhalb der Datenbank. Ändert sich ein Tabellenname, muss somit das entsprechende Tag in den Testdaten umbenannt werden.

Nehmen wir für das obige Beispiel an, dass die Tabelle USERS in BUDDIES umbenannt wurde. Durch die Übergabe des alten und des neuen Tabellen- bzw. Tag-Namens konvertiert der XML-Konverter die obige Testdatendatei wie folgt:

Beispiel 5.2. Testdaten-Beispiel nach Umbenennung der Tags

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <BUDDIES SURNAME="Simpson" NAME="Homer" BIRTHDATE="1946-09-16"/>
  <BUDDIES SURNAME="Simpson" NAME="Maggie" BIRTHDATE="2006-09-15"/>

  <SHOP_USERS SURNAME="Smithers" NAME="Waylon" RESERVED=""/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery" RESERVED=""/>
</dataset>


Der Tabellenname USERS wurde in den Testdaten durch den Namen BUDDIES ersetzt. Die Tabelle SHOP_USERS bleibt hingegen unverändert, obwohl der Name dieser Tabelle auch die Zeichenkette USERS beinhaltet.

5.3.1.2. Attribute umbenennen

Die Attribute der Tags in den Testdaten entsprechen den Spaltennamen in der Datenbank. Ändert sich ein Spaltenname in der Datenbank, muss das entsprechende Attribut geändert werden. In unserem Beispiel gehen wir davon aus, dass die Spalte NAME der Tabelle USERS in FIRSTNAME umbenannt wurde.

Dem checkerberry cockpit XML-Konverter wird der Name des alten Attributs (NAME), der Name des zugehörigen Tags (USERS) und der neue Name des Attributs (FIRSTNAME) übergeben. Das Ergebnis der Umbenennung sieht wie folgt aus:

Beispiel 5.3. Testdaten-Beispiel nach Umbenennung der Attribute

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <USERS SURNAME="Simpson" FIRSTNAME="Homer" BIRTHDATE="1946-09-16"/>
  <USERS SURNAME="Simpson" FIRSTNAME="Maggie" BIRTHDATE="2006-09-15"/>

  <SHOP_USERS SURNAME="Smithers" NAME="Waylon" RESERVED=""/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery" RESERVED=""/>
</dataset>


Der Attributname NAME wurde nur für die USERS-Tags umbenannt, obwohl das SHOP_USERS-Tag den Attributnamen NAME ebenfalls verwendet. An dieser Stelle wird deutlich, dass der XML-Konverter kontextsensitiv arbeitet. Die manuelle Umstellung wäre in diesem Fall sehr aufwändig und fehleranfällig. Aufgrund der Situation ist ein reines „Suchen & Ersetzen“ von NAME durch FIRSTNAME nicht möglich. Einige Editoren ermöglichen das „Suchen & Ersetzen“ über reguläre Ausdrücke. Dieses Vorgehen ist jedoch komplex und somit fehleranfällig.

5.3.1.3. Neue Attribute einfügen

In der Praxis tritt hin und wieder die Situation auf, dass neue Spalten in eine Datenbanktabelle eingefügt werden müssen. Wenn die Werte die Anwendung beeinflussen oder wenn es sich um Pflichtfelder handelt (not null), müssen diese neuen Spalten auch in den Testdaten berücksichtigt werden. Für das obige Beispiel nehmen wir an, dass in der Tabelle USERS die Spalte COUNTRY mit dem Default-Wert DE eingefügt wird.

Für die Anpassung der Testdaten wird dem checkerberry cockpit der Name des Tags (USERS), der Name des neuen Attributs (COUNTRY) und der Wert des Attributs (DE) übergeben. Das Ergebnis der Konvertierung sieht wie folgt aus:

Beispiel 5.4. Testdaten-Beispiel nach dem Einfügen eines neuen Attributs mit Default-Wert

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sampledb.dtd">

<dataset>
  <USERS SURNAME="Simpson" NAME="Homer" BIRTHDATE="1946-09-16" COUNTRY="DE"/>
  <USERS SURNAME="Simpson" NAME="Maggie" BIRTHDATE="2006-09-15" COUNTRY="DE"/>

  <SHOP_USERS SURNAME="Smithers" NAME="Waylon" RESERVED=""/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery" RESERVED=""/>
</dataset>


Die Definition eines Default-Werts ist in vielen Situationen ausreichend. Es besteht jedoch auch die Möglichkeit die Werte aus anderen Attributen des gleichen Datensatzes zu referenzieren. Eine Kombination von festen Texten und referenzierten Werten ist ebenfalls möglich. Als Beispiel könnte für die Tabelle USERS eine neue Spalte FULLNAME eingefügt werden, die den Vor- und Nachnamen beinhaltet. Zu diesem Zweck wird dem checkerberry cockpit XML-Konverter der Default-Wert „ ${NAME} ${SURNAME} “ übergeben. Das Ergebnis der Konvertierung sieht dann wie folgt aus:

Beispiel 5.5. Testdaten-Beispiel nach dem Einfügen eines neuen Attributs mit Referenzen

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <USERS SURNAME="Simpson" NAME="Homer" BIRTHDATE="1946-09-16"
    FULLNAME="Homer Simpson"/>
  <USERS SURNAME="Simpson" NAME="Maggie" BIRTHDATE="2006-09-15"
    FULLNAME="Maggie Simpson"/>

  <SHOP_USERS SURNAME="Smithers" NAME="Waylon" RESERVED=""/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery" RESERVED=""/>
</dataset>


Bei dem Einfügen eines neuen Attributs werden die referenzierten Attribute aus dem entsprechenden Datensatz extrahiert und als Wert des neuen Attributs eingefügt.

5.3.1.4. Bestehende Attribute löschen

Bei der Änderung der Datenbankstruktur kann es ebenfalls vorkommen, dass Spalten wegfallen. In den Testdaten müssen die entsprechenden Attribute ebenfalls entfernt werden, da anderenfalls die DTD-Validierung fehlschlägt. Spätestens beim Einspielen in die Datenbank kommt es zu einem Fehler, wenn die einzuspielende Spalte in der Datenbank unbekannt ist.

Für das Beispiel nehmen wir an, dass die Spalte RESERVED in der Tabelle SHOP_USERS entfallen soll. Zu diesem Zweck werden dem checkerberry cockpit XML-Konverter der Name des Tags (SHOP_USERS) und der Name des zu löschenden Attributs (RESERVED) übergeben. Das Ergebnis der Konvertierung sieht wie folgt aus:

Beispiel 5.6. Testdaten-Beispiel nach dem Löschen von Attributen

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE dataset PUBLIC "-//ConceptPeople//DTD sample-db 1.0//EN"
"../sample-db.dtd">

<dataset>
  <USERS SURNAME="Simpson" NAME="Homer" BIRTHDATE="1946-09-16"/>
  <USERS SURNAME="Simpson" NAME="Maggie" BIRTHDATE="2006-09-15"/>

  <SHOP_USERS SURNAME="Smithers" NAME="Waylon"/>
  <SHOP_USERS SURNAME="Burns" NAME="Montgomery"/>
</dataset>


Das Attribut wurde aus den Testdaten entfernt.

5.3.1.5. Adressierung von Tags und Attributen

Der checkerberry cockpit XML-Konverter benötigt bei der Konvertierung den Namen des Tags und teilweise auch den Namen des Attributs. Bei diesen Werten handelt es sich immer um die alten Namen der Werte. Folgendes Beispiel verdeutlicht die Problematik. Nehmen wir an, dass in unserem obigen Beispiel die Tabelle USERS in BUDDIES umbenannt werden soll. Des Weiteren soll in dieser Tabelle eine neue Spalte FULLNAME eingefügt werden. Bei der Definition der Parameter für die Anlage des Attributs FULLNAME stellt sich nun die Frage, ob das Tag noch über USERS oder schon über BUDDIES angesprochen werden muss. Wenn die Konvertierung innerhalb eines Schritts, d.h. innerhalb eines definierten Mappings durchgeführt wird, muss der alte Name der Tabelle referenziert werden. Wenn die Konvertierung über zwei verschiedene Aufrufe des XML-Konverters nacheinander erfolgt, muss verständlicherweise der neue Name verwendet werden, da der bisherige Name dann nicht mehr in den Testdaten bekannt ist.

Bei dem Hinzufügen von neuen Attributen können ebenfalls nur bestehende Attribute referenziert werden. Das Referenzieren von neuen Attributen liefert unvorhersehbare Ergebnisse.