Visual Studio Database Edition: Datenbanken testen

21. Februar 2011

Dieser Artikel ist Teil einer Serie über die Features der Visual Studio Database Edition. Hier die bisherigen Artikel:

1. Überblick
2. Datenbankschemas vergleichen
3. Deployment
4. Erstellen von Testdaten

Als Datenbank-Entwickler möchte man unbedingt sicherstellen, dass Stored Procedures, Functions und Trigger sich wie erwartet verhalten und Änderungen bestehende Funktionalität nicht beeinträchtigen.

Bei dieser Aufgabe bietet die Database Edition die Möglichkeit, einfach und schnell Datenbank Objekte zu testen. Somit kann sichergestellt werden, dass der aktuelle Stand der Datenbank wie erwartet funktioniert. Getestet werden können Stored Procedures, Functions, Trigger und jedes beliebige SQL-Skript.

Um einen Test zu erstellen, wechseln wir in die „Schema View“ View -> Database Schema View und navigieren zu den Stored Procedures. Schemas -> Programmability -> Stored Procedures und wählen eine Stored Proceudre mit Rechtsklick aus. Hier wählen wir „Create Unit Tests…“

clip_image001

Im folgenden Dialog wählen wir einen Namen für ein neues Testprojekt und drücken „OK“:

clip_image002

Das Testprojekt wird jetzt erstellt und die Testklasse im Editor geöffnet. Darüber hinaus öffnet sich ein Dialog, in welchem eine Datenbankverbindung für das Testprojekt ausgewählt werden muss. Die Tests laufen dann immer gegen die hier definierte Verbindung. Die Optionen „Deployment“ und „Database state“ ermöglichen es uns, vor dem Test die aktuelle Version des Datenbankprojektes einschließlich definierter Testdaten zu deployen.

clip_image003

Nachdem wir eine Datenbank ausgewählt haben, befinden wir uns im sog. Datenbank Unit Test Designer. Dieser ähnelt dem WinForms-Designer und bietet eine T-SQL Sicht auf Unit Tests.

clip_image005

Hier kann beliebiger SQL Code ausgeführt werden. Das Ergebnis der Ausführung wird mit so genannten „Test Conditions“ geprüft. Jede Test Condition stellt einen eigenen Test dar.

Folgende Testbedingungen sind möglich:

  • Data Checksum Prüft gegen eine Checksumme über alle Zeilen des Ergebnisses
  • Empty ResultSet Erwartet ein leeres Resultset
  • Execution Time Hier kann eine maximale Ausführungszeit angegeben werden, z.B. für Performance-Tests.
  • Expected Schema Definiert die erwartete Struktur (Tabellen und Spalten) des Ergebnisses
  • Inconclusive Standardbedigung um einen unvollständigen Test anzuzeigen
  • Not Empty ResultSet Prüft ob ein Ergebnis zurückgeliefert wurde
  • Row Count Prüft die Anzahl der zurückgelieferten Datensätze
  • Scalar Value Prüft auf ein erwartetes skalares Ergebnis

Als Beispiel für Unit Tests nehmen wir die Stored Procedure „Ten Most Expensive Products“, da diese ein einfach zu testendes Ergebnis liefert.

Zuerst löschen wir den vorhanden „Inconclusive Test“ und definieren dann einen neuen Row Count Test:

clip_image007

Als Ergebnis unserer Stored Procedure werden zehn Datensätze erwartet. Damit der Test im ersten Durchlauf fehlschlägt müssen wir darauf achten, dass die Anzahl der erwarteten Datensätze ungleich 10 ist.

clip_image008

Wir starten nun den Test, welcher wie erwartet fehlschlägt:

clip_image010

Damit der Test durchläuft setzen wir den Row Count auf 10:

clip_image011

Der Test läuft nun wie erwartet durch:

clip_image013

Die so erstellten Tests gliedern sich nahtlos in das MSTest Framework ein und lassen sich wie andere Unit Tests ausführen.