Gibt es ein Framework zum Schreiben von Komponententests für die Datenzugriffsebene? Hier gibt es mehrere Probleme.
1. Wie befüllen Sie Ihre Datenbank?
2. Wie stellen wir sicher, dass ein Test keine Werte in db ändert, die einen anderen Test nicht bestehen können?
Gibt es einen guten Rahmen, der sich um die oben genannten Probleme kümmern kann?
Update : Ich bin auf nDBUnit gestoßen, das sich um Infrastrukturprobleme beim Testen der Datenzugriffsebene kümmern kann.
Ich schätze, ich werde mitspielen, da ich einige der bisherigen Antworten wirklich nicht mag.
Ob Sie es einen "Komponententest" oder "Integrationstest" oder einen "Supercalifragilisticexpialidocious Test" nennen, spielt in diesem Fall keine Rolle; Es gibt nur einen gültigen Test für Datenzugriff -Komponenten und dass es auf tatsächlichen Daten getestet werden soll. Nicht Produktion Daten offensichtlich, aber ein vernünftiges Faksimile davon.
Das erste, was Sie tun müssen, ist Holen Sie sich die Datenbank selbst unter Quellcodeverwaltung . Leider gibt es dafür keinen Rahmen; Microsoft geht teilweise in einigen Versionen von VSTS, aber das Endergebnis fehlt noch etwas. Zumindest in der heutigen Zeit wirst du viel selbst tun müssen. Aber tu es, im Ernst - du wirst es nicht bereuen, wenn ein größeres Update verpfuscht wird und du die DB zurücksetzen musst.
Was Sie in die Quellcodeverwaltung eingeben, sollte alles sein, was notwendig ist, um das neueste Schema, normalerweise ein Basisskript, plus "Konfigurationsdaten" -Skripts (d. h. den Inhalt von Aufzählungstabellen) zu generieren und Skripten zu aktualisieren, um die jüngsten Schemaänderungen widerzuspiegeln. Dies gibt Ihnen fast alles, was Sie benötigen, um Live-Tests in einer temporären Datenbank durchzuführen. Ihr Test muss diese Skripts nur von der Quellcodeverwaltung herunterladen und auf einem Testserver und / oder einer anderen Datenbankinstanz ausführen, normalerweise unter Verwendung von SQL Management Objects , um diese Skripte auszuführen (SMO kann GO -Anweisungen und ähnliches verarbeiten; eine reguläre SqlConnection kann nicht).
Verschiedene Tools können Ihnen bei der Generierung von Testinhalt in der Testdatenbank helfen. Der wohl bekannteste ist der SQL Data Generator von Red Gate. Diese Tools können auch Skripte generieren, um die Daten zu erstellen, die Sie in Ihren Tests verwenden werden. Wenn Sie dies wünschen, können Sie die Daten aus Ihrer Produktionsdatenbank scrubben und mithilfe von SQL Server Management Studio beliebige Daten scripten, die Sie zum Testen behalten möchten. Wie auch immer, halten Sie Ihre Testdatenskripte wie die Schemaskripten in der Quellcodeverwaltung und wenn Sie Ihre DAL testen müssen, laden Sie diese Skripts nach dem Start einer DB-Instanz herunter und verwenden Sie sie zum Auffüllen der Daten.
Ich wünschte, es wäre ein einziges Framework, das Ihnen das alles bietet, aber mit der richtigen Sammlung von Tools, Bibliotheken und guten Entwicklungspraktiken können Sie können mache dies zu einem viel weniger schmerzhaften Prozess.
Wenn Sie Ihre Repositories testen, die auf die Datenbank zugreifen, müssen Sie immer sicherstellen, dass die Datenbank gelöscht wird, nachdem der Komponententest abgeschlossen ist. Sie können dies ausführen, indem Sie den Test unter der Transaktion ausführen, ODER Sie können das Rollback-Attribut MbUnit verwenden, um die Änderungen automatisch rückgängig zu machen.
Nicht. Unit Tests greifen nicht auf die db zu. Dafür stehen Integrations- oder Funktionstests.
Ich hätte eine Reihe von Tests, die bestätigen, dass der Code, der die db-Kommunikation verwaltet, das Richtige tut und dann so selten wie möglich anfasst.
Der Grund dafür, dies nicht in "Unit-Tests" zu tun, ist, dass Sie damit riskieren, die Bedeutung des Ausdrucks "Unit-Test" zu verwässern und sie zu einer Vielzahl von Tests zu machen langsamer und verhindern, dass Entwickler sie so häufig ausführen, wie sie sollten.
Tags und Links .net nunit tdd nhibernate