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.
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.
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.
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.
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.
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.
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.