Daniel Esser

In diesem Beitrag möchte ich euch zeigen wie man mit Visual Studio automatisierte Tests schreibt um z.B. die Einzelfunktionen eines SSIS Packages zu testen. Ihr könnt natürlich sofort mitklicken, dazu wird folgendes benötigt:

  • Visual Studio 2010 Premium oder Ultimate
  • SQL Server Data Tools (gemeint ist Visual Studio mit SQL Server 2012)
  • Installierten SQL Server 2012 und eine konfigurierte SSISDB

Als erstes legen wir die benötigten Projekte in Visual Studio an. Wir erstellen ein neues Integration Services Projekt mit dem Namen ‚SsisExample‘ und setzen den Solution Namen auf ‚SssisTestCaseExample‘. Als nächstes fügen wir der Solution ein weiteres Projekt hinzu und zwar ein unter Visual C# -> Test; das Projekt nennen wir ‚SsisTestCases‘. Im Solution Explorer sollte die Solution jetzt so aussehen:


Wie nehmen ein paar Änderungen an den Project- und Solution Properties vor. Dazu öffnen wir den Eigenschaften Dialog der Solution (Alt+Enter). Unter Common Properties -> Project Dependencies stellen wir unter Project ‚SssisTestCases‘ und unter Depends on ‚SsisExample‘ ein. Dies sorgt dafür, dass wenn wir die SSIS Pakete ändern diese vor der Ausführung der Test Cases übersetzt werden, schließlich wollen wir immer den aktuellsten Stand testen:

Nun öffenen wir im Projekt ‚SsisExample‘ das Paket ‚Package.dtsx‘ und fügen ihm einen Data Flow Task hinzu. Dann erstellen wir einen OLE-DB Connection Manager und unter Server Name tragen wir ‚localhost‘ (bzw. den Hostnamen des SQL Servers) und als Datenbank ‚master‘ ein. Dann wird eine OLE DB Source eingefügt. Anschließend editieren wir die Eigenschaften der Source und tragen den gerade erstellen Connection Manager ein. In Data Access Mode wird SQL Command ausgewählt und unter SQL Command text folgendens eingetragen: SELECT * FROM sys.databases.

Dann fügen wir eine Data Reader Destination ein und verbindinden die OLDE DB Source mit der Data Reader Destination. Je nachdem wieviele Datenbanken Ihr habt sollte das in etwa so aussehen:


Da wir nun ein einfaches SSIS Paket haben beschäftigen wir uns mit der Testautomatisierung, dazu öffnen wir das Testprojekt im Soluton Explorer. Visual Studio hat und einen Unit Test namens ‚UnitTest1.cs‘ angelegt welche allerdings nicht benötigt wird, also löschen wir den Test. Dann fügen wir einen neuen Test zum Projekt hinzu mit Add -> New Test. Im Add New Test Dialog wählen wir Database Unit Test aus. Als Testnamen wählen wir ‚SsisTest.cs‘. Als nächstes öffnet sich Konfigurationsdialog für den Datenbank Test. Dort erstellen wir unter Database Connection eine neue Connection und tragen bei Server den Namen des Servers ein auf dem die SSIS Pakete gestartet werden sollen (dies muss nicht unbedingt der lokale Rechner sein). Als Datenbank muss die Datenbank ‚SSISDB‘ ausgewählt sein.

Es öffnet sich der Datenbank-Test und oben links steht ‚DatabaseTest1‘. Wir klicken auf Rename rechts und benennen den Test um in ‚SimpleExecutionTest‘.

Anschließend klicken wir in der Mitte des Bildschirms auf ‚Click here to create‘. Wir sehen nun ein SQL Kommentar und in diesem Fenster können wir unsere SQL Queries eintragen die verschiedene Aspekte einer Datenbank testen. Unser Ziel ist es aber ein SSIS Paket zu starten und zu überprüfen ob es erfolgreich gelaufen ist. Was nun?

Zum Glück wurden mit dem SQL Server 2012 vieles von der SSIS-Funktionalität in den SQL Server selbst gehoben. Es gibt also eine ganze Reihe von Stored Procedures, die es uns erlauben Pakete direkt per TSQL zu starten. Sehen wir uns mal dazu folgendes SQL-Query an:

Im ersten Schritt wird eine Execution angelegt. Eine Execution in SSIS beschreibt die geplante Ausführung eines SSIS-Pakets. In den Parametern für die Execution wird der Name des Pakets, der Name des Verzeichnisses in dem das Paket auf dem Server gespeichert ist und der Name des Projektes dem das Paket angehört angegeben. Ferner könnte über @reference_id noch ein Environment zur weiteren konfiguration hinzugefügt werden (lassen wir der Einfachheit halber aber weg). Über @use32bitruntime kann gesteuert werden ob das Paket mit der 32 Bit- oder der 64-Bit-Runtime gestartet wird.

Nun lassen sich Aufrufe der Stored Procedure [set_execution_parameter_value] finden. Mit dieser Prozedur können Connection Manager, Project- und Package-Parameter sowie spezielle Ausführungsparameter gesetzt werden. Zwei von den speziellen Ausführungsparametern heißen LOGGING_LEVEL und SYNCHRONIZED. Das Logging-Level kann eine Zahl zwischen 0 und 3 (None, Basic, Performance und Verbose) sein. Für weitere Informationen empfehle ich das Technet. Mit SYNCHRONIZED kann die Prozedur synchron ausgeführt werden, das bedeutet die Prozedur wartet aktiv bis das Paket abgearbeitet worden ist (erfolgreich oder nicht). Dies ist in diesem Fall gewünscht, da wir direkt im Anschluß testen möchten ob das Paket erfolgreich gelaufen ist oder Fehler aufgetreten sind; diese Information liefert die Prozedur nämlich leider nicht direkt. Fügen wir also das Query dem Datenbank-Test hinzu und führen ihn aus.

Dazu sollte man die Solution Bauen, das SSIS-Projekt neu deployen und in die Test-View wechseln und mit Run Selection den Test ausführen:

Der Test läuft…

und schlägt fehl! Warum?

Wechseln wir kurz in das SQL Server Management Studio und schauen uns den Execution Report an:

Der oberste Eintrag ist unsere Execution und es ist alles gut gelaufen, zumindest auf der SSIS-Seite.

Die Lösung ist wir haben die Testbedingungen noch nicht spezifiziert. Standardmäßig schlägt jeder neue Datenbanktest mit einer Testbedingung „Inconclusive“ fehl. Wir löschen diese Testbedingung.

Schauen wir uns das letzte Select nocheinmal an: in dem Select-Statement wird die Tabelle [executions] der SSIDB abgefragt. Dort sind alle Executions verzeichnet, ob gestartet oder nicht und ob erfolgreich durchgelaufen oder nicht. Mit der Execution Id können wir den Status abfragen. Der Status ist eine Zahl zwischen 1 und 9; die Werte sind oben erklärt und können auch im Technet nachgelesen werden.

Nun fügen wir dem Test die Test Condition vom Typ Scalar Value hinzu. Alt-Enter oder über das Kontextmenü zum editieren der Eigenschaften. Null expected auf False und Expected Value auf 7 (Succeeded) setzen.

Jetzt starten wir den Test erneut…

und es klappt. Ein Doppelklick auf den Test-Result öffnet den Test-Report. Fehler sowie die PRINT-Ausgabe der Execution Id können hier nachgelesen werden.

Sonstiges

Sollte euch ein Timeout begegnen könnt ihr diesen in der app.config einstellen:

Fazit

Auf einfache Art und Weise haben wir uns einen Datenabank-Test geschrieben der ein SSIS-Paket aufruft und prüft ob es erfolgreich durchgelaufen ist. Das Query kann jetzt z.B.  so erweitert werden, dass fachliche Tabellen die das Paket als Ausgabe befüllt inhaltlich getestet werden. Dazu kann der Scalar Value Test oder auf der Data Checksum Test verwendet werden. Natürlich können auch noch weitere Tests für andere Pakete hinzugefügt werden. Es ist sogar möglich über Pre- und Post-Tests erst Beispieldaten zu laden und anschließend wieder zu löschen. Auch können die SQL-Queries parametrisiert werden, aber das alles würde den Rahmen dieses Beitrags hier sprengen.

Später mehr dazu … viel Spaß beim testen!