Unit Testing TSQL

Question

Gibt es jemand da draußen Unit-Tests für ihre TSQL gespeicherte Prozeduren zu schreiben, Trigger, Funktionen ... etc.

ich vor kurzem habe angefangen, Datenbank und Wiederherstellungen und installiert ist Teil unserer automatisierten Cruise Control build verarbeiten. Jetzt denke ich darüber nach, es auf die nächste Ebene zu bringen, wo wir die Installation durchführen, dann durch eine Liste gespeicherter Prozedurtests usw. laufen.

Ich wollte nur meine eigene mit MsBuild Extensions rollen, um die Tests aufzurufen. Allerdings bin ich mir bewusst von http://www.tsqltest.org/ und http://tsqlunit.sourceforge.net/. Ich bin mir auch bewusst, dass TFS SQL-Tests hat.

Ich wollte nur sehen, was Menschen in der realen Welt tun und ob sie irgendwelche Vorschläge haben.

Dank

Answer 1

Ich habe die Datenbank-Tests verwendet, die in Visual Studio 2008 Database Edition auf einem Projekt hier gebaut wird. Es funktioniert gut, fühlt sich aber eher wie ein Drittanbieter an, der in Visual Studio integriert ist, als eine native Komponente. Einige der Schmerzen, die ich mit ihm gefühlt sind:

• Da in den Res-Dateien SQL-Code lebt und eine einzige Code-Datei kann mehrere Tests umfassen, ist es nicht so einfach ist, für welches Tests basierend auf Tabelle/Spaltennamen zu suchen.
• Da mehrere Tests in denselben Code-Dateien gespeichert sind, haben Sie einige lästige Namenskonflikte (wenn Sie beispielsweise zwei Tests in einer einzigen Codedatei haben, müssen alle Assertionen für diese Tests eindeutige Namen haben Assertionsnamen werden wahrscheinlich wie "testname_assertionsname" aussehen, was eigentlich nicht notwendig sein sollte.
• Refactoring Ihrer Tests ist nicht einfach - zum Beispiel, wenn Sie einen Test von einer Codedatei zu einer anderen verschieben möchten, ist der einfachste Weg, den Test von Grund auf in der neuen Datei zu erstellen, da es Teile des Tests gibt verstreut über die Res-Datei und die Codedatei.

All das gesagt, wie ich begann mit - Es funktioniert gut. Leider haben wir diese Tests noch nicht unserem Continuous Integration Server hinzugefügt, daher kann ich nicht sagen, wie einfach es ist, den Testlauf zu automatisieren. Wir verwenden TFS für CI, und ich gehe davon aus, dass die Automatisierung der Tests der Automatisierung von Standard-Komponententests sehr ähnlich wäre; Mit anderen Worten, es scheint, dass es eine MSTest-Befehlszeile geben sollte, die die Tests ausführen würde.

Natürlich ist dies nur eine Option, wenn Sie eine Lizenz für die Visual Studio 2008 DB Edition besitzen (von der ich weiß, dass sie jetzt in der VS 2008 Pro-Lizenz enthalten ist).

Answer 2

Gespeicherte Prozeduren. Im Allgemeinen schließe ich Testabfragen in Kommentare im SP-Header ein und zeichne korrekte Ergebnisse und Abfragezeiten auf. Dies bleibt jedoch immer noch eine manuelle Übung.)

Funktionen. Setzen Sie wiederum SQL-Anweisungen in die Kopfzeile mit den gleichen Informationen.

Auslöser. Ich vermeide sie aus einer Reihe von Gründen, eine davon ist, dass sie so schwer zu testen und zu debuggen sind, für einen so geringen Vorteil, verglichen mit der gleichen Logik in einer anderen Schicht. Es ist, als würde man fragen, wie man auf referenzielle Integrität testet.

Dies ist jedoch immer noch ein manueller Prozess. Aber da ich denke, dass man absichtlich SQL-Artefakte so gestalten sollte, dass sie vollständig entkoppelt sind (z. B. keine SPs, die SPs aufrufen, dasselbe mit Funktionen und ein anderes Strike gegen Trigger IMHO), ist es relativ weniger komplex.

Answer 3

Die kritischen Teile:

• Machen Sie es und mit Ihrem Build/Test integriert automatisierte (so haben Sie eine grün oder rot von Build)
• Machen Sie es einfach ein hinzufügen neue Test
• Halten Sie Ihre Tests up-to-date

Advanced:

• Testfehlerbedingungen in Ihrem Code
• stellen Sie sicher, Ihre Tests aufzuräumen nach selbst (TSqlTest dem Beispiel Skripte verwenden @beforeCount und @afterCount Variablen die clean-up zu validieren)

Answer 4

Ich habe dies in Java mit dbunit getan.

Grundsätzlich gibt alles, was Sie in der Datenbank tun: gibt eine Ergebnismenge zurück oder ändert den Zustand der Datenbank.

Der Status der Datenbank kann als alle Werte in allen Zeilen in der gesamten Tabelle in allen Schemas einer Datenbank beschrieben werden; Der Status einer Teilmenge ist der Zustand aller Daten, die durch einen Test beeinflusst werden.

Beginnen Sie also mit einer Datenbank, die mit genügend Testdaten gefüllt ist, die Sie Tests durchführen können, nennen Sie dies die Grundlinie. Extrahieren Sie einen Snapshot mit dbunit oder dem Tool Ihrer Wahl.

Vorausgesetzt, dass Ihre Datenbank zu Beginn ist, ist jede Ergebnismenge deterministisch (solange Ihr sp ist deterministisch, weniger so, wenn es ein "select random();").

Holen Sie sich die Baseline-Ergebnismenge aller Ihrer SPs, speichern Sie diese als Snapshots mit dbunit oder einem anderen Tool, das Sie verwenden.

Um Operationen zu testen, die den Status nicht ändern, testen Sie einfach, dass die Ergebnismenge diejenige ist, die Sie ursprünglich erhalten haben. Um Operationen zu testen, die die Datenbank ändern, testen Sie diese Baseline + Operation = erwartete Änderung. Nach jedem Test, der möglicherweise die db verändert, rüste es auf Basislinie auf.

Grundsätzlich ermöglicht die Möglichkeit zur Wiederherstellung auf eine Grundlinie das Testen.

Answer 5

Haben Sie versucht, die API von red-gate.com zu verwenden?

Sie haben eine Reihe von Produkten zum Vergleichen von Dingen in SQL Server und die API ermöglicht praktisch die gleiche Funktionalität programmgesteuert.

http://help.red-gate.com/help/SQLDataCompareAPIv5/4/en/GettingStartedAPI.html