Wie kann ich Datenbankmigrationen testen?

Question

Ich verwende Migrator.NET, um Datenbankmigrationen für die Anwendung zu schreiben. Marc-André Cournoyer schrieb:

Wie jeder Code in Ihrer Anwendung Sie müssen Ihre Migrationen testen. Ups und Downs Code. Machen Sie einen Teil Ihres kontinuierlichen Build-Prozesses und testen Sie ihn auf auf so viele verschiedene Datenbanken und Umgebung, wie Sie können.

Wie mache ich das? Angenommen, ich habe die Methode Up(), die eine Tabelle erstellt, und die Methode Down(), die dieselbe Tabelle löscht, und ich verwende SQL Server. Wie würde ein Test aussehen? Sollte ich SQL-Abfrage für die Systemtabellen ausführen, wie select * from sys.columns, um zu überprüfen, ob die Tabelle erstellt wurde und die richtige Struktur hat? Was ist, wenn wir NHibernate verwenden?

EDIT ich meine Migrationen in den Schienen Active Migrations Sinn (Erstellen, Modifizieren und Datenbanken in kleinen Schritten auf C# Code basiert abzureißen).

EDIT 2 Und here ist, wo ich gelesen, dass wir Migrationen testen. Der Blogpost ist tatsächlich mit dem Migrator-Wiki verlinkt.

Answer 1

Testen Sie Ihren DAL - eine Art Integrationstest?

Sie benötigen mehr als ein Migrationsskript, Sie benötigen auch ein Basislinienskript. Wenn Sie eine Datenbankaktualisierung testen möchten, sollten Sie alle Skripts von der Baseline auf einem Test-/Staging-Server ausführen, um die neueste Version der Datenbank zu erstellen. Dann testen Sie Ihre DAL mit der aktuellen Testdatenbank. Wenn alle DAL-Tests erfolgreich sind, sollte Ihre Migration erfolgreich verlaufen sein (andernfalls sind Ihre DAL-Tests nicht vollständig genug).

Es ist ein teurer Test zu laufen, aber es ist ziemlich felsenfest. Ich werde persönlich zugeben, dass ich im Moment viel manuell mache; Wir verfügen über ein internes Migrationstool, das alle Skripts (einschließlich der Baseline) anwendet. Daher sind die Testdatenbankeinrichtung und DAL-Tests separate Schritte. Es funktioniert aber. Wenn Sie sicherstellen möchten, dass eine Tabelle erstellt wurde, gibt es keine bessere Methode, als tatsächlich Daten einzufügen!

Sie können versuchen, die Ergebnisse zu überprüfen, indem Sie auf Systemkatalogen und INFORMATION_SCHEMA Ansichten suchen und so weiter, aber letztlich der einzige Weg, um sicher zu sein, es ist eigentlich Arbeits die neuen Objekte zu Gebrauch zu versuchen. Nur weil die Objekte da sind, heißt das nicht, dass sie funktional sind.

Answer 2

vielleicht kann dieses Scrip Ihnen helfen:

http://www.benzzon.se/forum/uploads/benzzon/2006-03-27_134824_sp_CompareDB.txt

dieses Skript vergleicht zwei db (Struktur und Daten)

Answer 3

Quellcodeverwaltung ist für einen Schnappschuss der aktuellen Codebasis nehmen.. Die Migration dient dazu, Ihre Datenbank von einer Version zur nächsten zu verschieben. So können Sie zu einem späteren Zeitpunkt eine alte Datenbank verwenden, Migrationen anwenden und mit der neuesten Codebasis arbeiten.

Ich habe nie die tatsächlichen Migrationen getestet. Ich habe gesehen, dass die Ergebnisse getestet wurden, und sie haben mich dazu gebracht/daran erinnert, die neuesten Migrationen durchzuführen.

describe User do 
    it { should have_column :name, :type => :string } 
    it { should validate_presence_of :name}  
end 

So jemand ändert das Modell. Fügt einen Test hinzu, um das Modell wiederzugeben. Fügt die Migration hinzu. Dann legt die Quelle fest.
Sie greifen die neuesten, führen Sie Tests. Tests schlagen fehl, weil die Datenbank nicht übereinstimmt. Sie erinnern sich daran, Migrationen auszuführen und dann Tests erneut auszuführen. Erfolg.

Answer 4

Sie könnten einen Vergleich von Datenbanksystemobjekten durchführen, aber Sie müssten ein Ziel haben, mit dem Sie vergleichen können - sonst wie würden Sie wissen, ob bestanden oder nicht bestanden?

Ich denke, Sie können besser eine Reihe von Randfall CRUD Operation Testfälle erstellen, die die Entitäten oder Operationen in der Datenschicht ausüben. Wenn einer dieser Fehler auftritt, ist die Datenbank nicht mit den erforderlichen Daten synchronisiert. d.h. wenn das Einfügen eines Feldzeichens (20) fehlschlägt, weil es nur ein Zeichen (15) in der Datenbank ist. Dann kann der Datenbankstrukturvergleich durchgeführt werden, um zu sehen, was wenn aus ist.

Sie können dies möglicherweise kurzschließen, indem Sie sich nur auf die zuletzt geänderten Elemente konzentrieren und vorausgesetzte Änderungen übernehmen.

Answer 5

Behandeln Sie Migrations-Tests als Teil Ihrer Gesamtpersistenz-Teststrategie, wenn Sie NHibernate, d.Wenn Sie alle Ihre Entitäten ohne Fehler erstellen und speichern können, sollte Ihre Datenbank und Ihre Mappings korrekt sein.

Answer 6

Ich bin auf der Suche nach einer Antwort auf diese auch. Ich denke, das sollte in einer Integrationsumgebung statt in einem Unit Test getestet werden: Für Unit Tests (DAL) lasse ich die Datenbank fallen und erzeuge sie neu.

Idealerweise hätte ich gerne eine Integrationsumgebung, in der meine Datenbank aus der Produktion repliziert wird und DB-Migrationsskripts in beide Richtungen laufen: Aufwärts, um ein reibungsloses Upgrade der Produktion zu gewährleisten, um Rollbacks zu ermöglichen.