Ich bin gerade dabei, unsere Lösung zu testen, die den gesamten "Gamut" von Layern aufweist: UI, Middle und die allgegenwärtige Datenbank.
Vor meiner Ankunft in meinem aktuellen Team wurden Abfragetests von den Testern durchgeführt, die manuell Abfragen erstellten, die theoretisch eine Ergebnismenge zurückgeben würden, die die gespeicherte Prozedur basierend auf verschiedenen Relevanzregeln, Sortierung, zurückgeben sollte.
Dies hatte den Nebeneffekt, dass Bugs häufiger gegen die Abfrage des Testers eingereicht wurden als gegen die eigentliche Abfrage.
Ich habe vorgeschlagen, tatsächlich mit einer bekannten Ergebnismenge zu arbeiten, die Sie einfach herausfinden könnten, wie sie zurückkehren sollte, da Sie die vorhandenen Daten kontrollieren - zuvor wurden Daten aus der Produktion genommen, bereinigt und dann in unsere Testdatenbanken eingefügt >
Die Leute bestanden immer noch darauf, eigene Abfragen zu erstellen, um zu testen, was die Entwickler erstellt haben. Ich vermute, dass viele noch sind. Ich bin der Meinung, dass dies überhaupt nicht ideal ist, und erhöht unnötig unsere Testfläche.
Also, ich bin neugierig, welche Praktiken verwenden Sie, um Szenarien wie diese zu testen, und was wäre ideal für die beste End-to-End-Abdeckung, die Sie erhalten können, ohne chaotische Daten einzuführen?
Das Problem, das ich habe, ist, wo man am besten testen kann. 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.
Das Testen von gespeicherten Prozeduren erfordert, dass jede Person, die testet, eine separate Instanz der Datenbank hat. 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 außerdem 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 Standard-Komponententests, so dass sie wahrscheinlich etwas sind, das Sie über Nacht laufen lassen wollen.
Es gibt ein paar Tools, die Ihnen dabei helfen können. DbUnit ist einer von ihnen und ich glaube auch, Microsoft hatte ein Tool Visual Studio für Datenbank-Profis, die einige Unterstützung für DB-Tests enthielt.
Hier sind einige Richtlinien:
Siehe den folgenden Link für die Enterprise-Services-Transaktionstechnik:
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 werden zeitlich abgestimmt, um sicherzustellen, dass:
1 / Sie brauchen nicht zu lange.
2 / Sie unterscheiden sich nicht stark (in einer schlechten Art) von der vorherigen Nacht.
Auf diese Weise erhalten wir schnell fehlerhafte Abfragen oder DB-Änderungen.
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 Ihre App zum Stillstand kommt.
Wir haben eine leere Datenbank für jeden Entwickler und Tester reserviert.
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 in der gleichen Datenbank testen (eine nach der anderen) und wir stempeln niemals anderen Prüfern Zehen.
Dies umfasst das Testen des Datenzugriffs selbst. 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 etc ..)
Django bietet eine Testfunktion für Datenbankeinheiten. Sie können ihre Designideen ausleihen und in anderen Umgebungen reproduzieren.
Die Django-Leute bieten eine Unterklasse von Pythons Standard-Unittest-Klasse TestCase an, die eine Datenbank mit einem bekannten Fixture füllt - eine bekannte Menge 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 TestCase Unterklasse ermöglicht das Schreiben eines typischen Testfalles, der die Datenbank mit dem bekannten Data Fixture auswertet.
Zusätzlich 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 Sie diese nicht zur Verfügung haben, benötigen Sie immer noch das DDL-Skript, damit Sie ein Testschema für Unittest-Zwecke erstellen und entsorgen können.
SQLServerCentral hat einen Artikel hier (Sie müssen sich vielleicht registrieren, aber es ist kostenlos und ohne Folgen) ein TSQL Unit Testing Framework namens tsqlUnit. Es ist Open Source und folgt in der Tradition des xUnit-Frameworks.
Es folgt das SEAT TDD-Muster:
Setup - Bereiten Sie die Testbedingungen vor, indem Sie die Objekte, Tabellen und / oder Daten manipulieren
Übung - rufen Sie den Produktionscode auf
Assert - Überprüfen Sie, ob das tatsächliche Ergebnis dem erwarteten Ergebnis entspricht
Teardown - gib alles zurück, so wie es vor dem Test war. Dies geschieht tatsächlich, indem eine Transaktion rückgängig gemacht wird, was alles schön und sauber hält.
Obwohl ich es nicht benutzt habe, sieht es vielversprechend aus und ist sicherlich etwas, das ich genauer betrachten werde.
Das Framework kann hier heruntergeladen werden.
Ich finde es nützlich, das SQL zu testen, das 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 testen, als die Datenbank zu viel zu heben.
Tags und Links database tdd integration-testing end-to-end