Welche Best Practices verwenden Sie zum Testen von Datenbankabfragen?

Question

Ich bin gerade dabei, unsere Lösung zu testen, die den ganzen "Gamut" von Layern hat: UI, Middle und die allgegenwärtige Datenbank.

Bevor ich in mein aktuelles Team kam, wurden Abfragetests durchgeführt, indem die Tester manuell Abfragen erstellten, die theoretisch eine Ergebnismenge zurückgaben, die die gespeicherte Prozedur basierend auf verschiedenen Relevanzregeln, Sortierung, zurückgab.

Dies hatte die Nebenwirkung von Bugs gegen die Abfrage des Testers öfter als gegen die eigentliche Abfrage in Frage gestellt.

Ich schlug vor, tatsächlich mit einem bekannten Ergebnissatz zu arbeiten, den Sie einfach ableiten könnten, wie es zurückkommen soll, da Sie die vorhandenen Daten kontrollieren - zuvor wurden Daten aus der Produktion genommen, bereinigt und dann in unsere Testdatenbanken eingefügt.

Die Leute waren immer noch darauf beharrlich, ihre eigenen Abfragen zu erstellen, um zu testen, was die Entwickler erstellt haben. Ich vermute, dass viele noch sind. Ich bin der Meinung, dass dies alles andere als ideal ist, und vergrößert unsere Testfläche unnötig.

Also, ich bin neugierig, welche Praktiken verwenden Sie, um Szenarien wie diese zu testen, und was wäre ideal für die beste Ende-zu-Ende-Abdeckung, die Sie erhalten können, ohne chaotische Daten einzuführen?

Das Problem, das ich habe, ist, wo ist der beste Ort, um was zu testen. Stoße ich den Dienst direkt an und vergleiche diesen Datensatz mit dem, den ich aus der gespeicherten Prozedur ziehen kann? Ich habe eine ungefähre Vorstellung und bin bisher erfolgreich genug gewesen, aber ich fühle, dass wir hier noch etwas Wichtiges vermissen, also schaue ich auf die Community, um zu sehen, ob sie wertvolle Einsichten haben, die bei der Formulierung meines Testansatzes helfen könnten besser.

Answer 1

Das Testen von gespeicherten Prozeduren erfordert, dass jede Person, die testet, über eine separate Instanz der Datenbank verfügt. Dies ist eine Voraussetzung. Wenn Sie Umgebungen freigeben, können Sie sich nicht auf die Ergebnisse Ihres Tests verlassen. Sie werden wertlos sein.

Sie müssen auch sicherstellen, dass Sie die Datenbank nach jedem Test in den vorherigen Zustand zurücksetzen, damit die Ergebnisse vorhersehbar und stabil sind. Aufgrund dieser Notwendigkeit, den Zustand nach jedem Test zurückzusetzen, werden diese Tests sehr viel länger dauern als standardmäßige Komponententests, so dass sie wahrscheinlich etwas sind, das Sie über Nacht laufen lassen wollen.

Es gibt ein paar Tools da draußen, die Ihnen dabei helfen. DbUnit ist einer von ihnen und ich glaube auch, dass Microsoft ein Tool Visual Studio für Datenbank-Profis hatte, das einige Unterstützung für DB-Tests enthielt.

Answer 2

Im Rahmen unserer kontinuierlichen Integration führen wir unseren nächtlichen "Build" der Datenbankabfragen durch. Hierbei handelt es sich um eine Reihe von DB-Aufrufen, die regelmäßig von den tatsächlichen Aufrufen im Code sowie von allen erwarteten Ad-hoc-Abfragen aktualisiert werden.

Diese Anrufe zeitlich gesteuert, um sicherzustellen,

1/Sie haben nicht zu lange dauern.

2/Sie unterscheiden sich nicht stark (in einer schlechten Art) von der vorherigen Nacht.

Auf diese Weise fangen wir fehlerhafte Abfragen oder DB Änderungen schnell.

Answer 3

Hier sind einige Richtlinien:

1. Verwenden Sie eine isolierte Datenbank für Unit-Tests (zB keine weiteren Testläufen oder Aktivität)
2. Setzen Sie immer alle Testdaten, die Sie im gleichen Test zu abfragen beabsichtigen
3. Schreiben Sie die Tests, um nach dem Zufallsprinzip verschiedene Datenmengen zu erstellen, z Zufallszahl von Einsätzen etwa zwischen 1 und 10 Reihen
4. die Daten randomisieren z.B. für einen boolean Feld Zufall Einsatz und wahr oder falsch
5. eine Zählung im Test der Variablen halten (zB Anzahl der Zeilen, die Anzahl der trues)
6. Für die Abfrage Asserts ausführen und vergleichen gegen lokale Testvariablen
7. Verwenden Unternehmen die Dienstleistungen Transaktionen Datenbank zur vorherigen Zustand

Siehe den Link unten für die Unternehmen die Dienstleistungen Transaktionstechnik Rollback:

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

Answer 4

Der Abfrageplaner ist gerade in diesem Fall Ihr Freund. Es ist immer eine gute Vorgehensweise, zu überprüfen, ob Indizes verwendet werden, wenn Sie dies erwarten und dass für die Abfrage keine zusätzlichen Arbeiten erforderlich sind. Selbst wenn Sie Stresstests in Ihrer Suite haben, ist es dennoch eine gute Idee, teure Abfragen zu erfassen, bevor die App zum Stillstand kommt.

Answer 5

Ich finde es nützlich, die SQL zu testen, die an die Datenbank gesendet wird, anstatt das Ergebnis der Abfrage der Datenbank.

Nicht, dass ich das später nicht mache, aber ich finde es viel schneller, dafür zu prüfen, als die Datenbank zu viel heben zu lassen.

Answer 6

Wir haben eine leere Datenbank für jeden Entwickler und Tester zur Seite stellen.

Wenn die Tests ausgeführt werden - jeder Test löscht die Datenbank und lädt die erwarteten Daten. Dies gibt uns jederzeit einen bekannten Zustand.

Wir können dann mehrere verschiedene Szenarien auf der gleichen DB testen (eine nach der anderen) und wir stempeln nie auf andere Tester Zehen.

, dass der Datenzugriff selbst deckt testen. Für Service-Tests machen wir das gleiche, aber wir testen nur das Innere des Service - wir treffen nicht den Service, den wir erstellen, eine Instanz der Service-Verarbeitungsklasse und geben alles ein, was wir brauchen. Auf diese Weise testen wir den Code und nicht die Infrastruktur (Nachricht usw.).

Answer 7

Django bietet eine Datenbankeinheit Testfunktion. Sie können ihre Designideen ausleihen und in anderen Umgebungen reproduzieren.

Die Django-Benutzer bieten eine Unterklasse von Pythons Standardeinheitentest TestCase Klasse, die eine Datenbank mit einem bekannten Fixture füllt - eine bekannte Reihe von Datenzeilen.

Im Fall von Django (und Python) ist es am einfachsten, die Datenbank aus einem JSON-Datenextrakt zu füllen. Andere Dateiformate für das Fixture können für andere Frameworks verwendet werden. Wenn Sie beispielsweise in Oracle arbeiten, können Sie CSV-Dateien leichter verwenden.

Diese Unterklasse TestCase ermöglicht das Schreiben eines typisch aussehenden Testfalls, der die Datenbank mit dem bekannten Data Fixture ausführt.

Darüber hinaus erstellt der Django-Test-Runner ein temporäres Schema für Testzwecke. Dies ist für Django einfach, da sie über eine vollständige objektrelationale Verwaltungskomponente mit DDL-Erstellung verfügen. Wenn diese Option nicht verfügbar ist, benötigen Sie weiterhin das DDL-Skript, damit Sie ein Testschema für Unittest-Zwecke erstellen und löschen können.

Answer 8

SQLServerCentral hat einen Artikel here (Sie müssen möglicherweise registrieren, aber es ist kostenlos und ohne Zeichenfolgen) über ein TSQL Unit Testing Framework namens tsqlUnit. Es ist Open Source und folgt in der Tradition des xUnit-Frameworks.

es der Sitz TDD Muster folgt:

Einrichtung - die Testbedingungen vorbereiten, indem die Objekte, Tabellen bearbeiten und/oder Daten

Übung -

Assert die Produktion Code aufrufen - prüfen, ob das tatsächliche Ergebnis entspricht dem erwarteten Ergebnis

Teardown - geben Sie alles zurück, wie es vor dem Test war. Dies geschieht tatsächlich durch das Zurückrollen einer Transaktion, die alles schön und sauber hält.

Obwohl ich es nicht verwendet habe, sieht es vielversprechend aus und ist sicherlich etwas, das ich genauer betrachten werde.

Das Framework kann here heruntergeladen werden.