TDD für Datenbanken – Microsoft SQL Server Database Unit Tests

Automatisierte Tests für Microsoft SQL Server? In vielen Punkten wird die Datenbank vernachlässigt und unterschätzt. Was schon lange Alltag in der Softwareentwicklung gängiger Programmiersprachen ist, wird im Datenbankumfeld oft nicht genutzt. Heute möchte ich Euch zeigen, wie Ihr Unit Tests für Datenbanken nutzen könnt.

„Kostet Testen nicht unglaublich viel Zeit und Aufwand?“ – Diese Antwort würde ich geben, wenn man mich fragt: „Welche ist die meist gestellte Frage, die du so hörst?“ Einfache Antwort: NEIN! Ausführlichere Antwort: Natürlich kostet es Zeit, einen Test zu entwickeln. Allerdings darf man nie vergessen, dass es auch Vorteile hat. Zum Beispiel im SQL Server Bereich, wo oftmals Fremddaten ins Datawarehouse geladen werden, kann man wunderbar die Datenqualität mit Database Unit Tests überprüfen. Zu jedem Zeitpunkt, immer und immer wieder. Wenn man zusätzlich noch Ansätze vom TDD (test driven development) nutzt, dann kann man einen großen Mehrwert erwirken. Wenn wir erst unsere Tests schreiben und dann gegen die Tests entwickeln, ist zum einen unser Endergebnis klar definiert, zum anderen können wir bei jeder Änderung an den Quelldaten automatisiert prüfen lassen, ob unsere Anwendung noch einwandfrei funktioniert. Tests sind nicht nur Teil der Entwicklung, sondern können später auch dazu genutzt werden, dauerhaft den Zustand unseres Datenbanksystems zu kontrollieren. Auch die Performance von Datenbankabfragen kann dauerhaft überwacht werden.

Gerade wenn ihr eure Datenbanksysteme mit Visual Studio Database Project entwickelt, ist der Aufwand, zusätzlich noch Database Tests einzubauen, sehr überschaubar. Um Database Unit Tests zu erstellen, müssen wir im Visual Studio erst einmal ein neues Unit Test Project (C#) anlegen.

Nachdem wir unser Database Project angelegt haben, sind wir auch schon in der Lage, den ersten Unit Test zu entwickeln. Ich habe für dieses Beispiel eine kleine Tabelle mit Mitarbeiter Personalnummern angelegt und möchte jetzt automatisiert prüfen, ob in dieser Tabelle doppelte Datensätze vorhanden sind. Hierzu klicken wir bei dem Projekt auf Add New Item und wählen auf der linken Seite SQL Server. Als Nächstes legen wir ein SQL Server Unit Test an.

Bei dem ersten angelegten Test erhalten wir eine Abfrage nach der Testkonfiguration.

Nachdem wir eine Connection für unseren Test angelegt haben, sind wir in der Lage, unseren Test zu entwickeln. Grundsätzlich kann nach folgenden Regeln getestet werden:

• Data Checksum
• Empty ResultSet
• Execution Time
• Expected Schema
• Inconclusive
• Not Empty ResultSet
• Row Count
• Scalar Value

Für meinen ersten Demo-Test nutze ich zwei Regeln. Die erste, um zu prüfen, ob überhaupt Daten in der Tabelle sind und die andere, um nach doppelten Datensätzen zu suchen.

Um den ersten Test anzulegen, wähle ich die Regel Not Empty Resultset und schreibe im Entwicklungsbereich ein SELECT auf meine Mitarbeiter-Liste. Damit später das Testergebnis aussagekräftig ist, vergebe ich noch einen sinnvollen Namen in den Eigenschaften. In diesem Fall bleibt die Eigenschaft Resultset auf 1 stehen.  Jedes SELECT in unserem Entwicklungsbereich erzeugt ein Resultset. Füge ich ein weiteres SELECT hinzu, ist dieses das Resultset 2.

Im Menü unter TEST -> Run -> All Tests (CRTL+R, A) kann ich diesen Test ausführen. Im Visual Studio erscheint in der linken Spalte ein Test Explorer, welcher mir das Ergebnis meines Testes anzeigt.

Anmerkung: Es macht durchaus Sinn, auch mal den Test zu testen, ob dieser korrekt funktioniert.

Als Nächstes füge ich meinen zweiten Schritt hinzu, wo ich nach doppelten Datensätzen suche. Hierfür nutze ich ein einfaches Query, welches mir alle Personalnummern anzeigt, welche doppelt vorkommen.

SELECT * FROM (
	SELECT ID, COUNT(ID) as Counted FROM [dbo].[Employees]
GROUP BY ID) as Result
WHERE Counted > 1

Für meinen Test nutze ich den Typ Empty ResultSet, denn im Idealfall gibt mir dieses Query alle die IDs aus, welche mehr als einmal vorkommen. Sollte also eine doppelte ID in diesem Statement zu finden sein, dann würde unser Test fehlschlagen. Zur Probe habe ich einmal einen doppelten Datensatz erzeugt und mir wird beim Ausführen sofort ein Fehler angezeigt.

Wie erwartet, ist der Test fehlgeschlagen mit dem Ergebnis:

Result Message: EmptyResultSetCondition Condition (TestDuplicatesIDs) Failed: ResultSet 2 was not empty.

Dieser Fehler kam zustande, da ich einen doppelten Datensatz in meiner Employees-Tabelle hatte. Lösche ich diesen, funktioniert der Test einwandfrei mit einem positiven Ergebnis.

Ich hoffe, Euch hat diese kleine Einführung in die Welt der Unit Tests für Datenbanken Spaß gemacht und freue mich, wie üblich, auf Euer Feedback.

Haben Sie Fragen zu diesem Artikel oder brauchen Sie Unterstützung?

Nehmen Sie mit uns Kontakt auf!

Wir unterstützen Sie gerne bei Ihren Vorhaben!