Tipps zum SSDT-Entwicklungsprozess und Best Practices bezüglich automatisierter Unit-/Integrationstests

Question

Ich suche seit Tagen in verschiedenen Foren, Blogs, MSDN usw., aber bisher konnte ich keine Anleitungen zu diesem Thema finden. Ich werde versuchen, diesen Beitrag ausführlicher zu erklären, weil ich denke, dass Informationen und Dokumentation der SSDT-Entwicklung nicht gut dokumentiert sind und es kein Best-Practice-Dokument wie VS 2010-Datenbankprojekte gibt (http://vsdatabaseguide.codeplex.com/).

Ich bin ein C# -Entwickler (kein DBA) und wir sind am Anfang der Entwicklungsphase eines Greenfield-Projekts (10 - 15 Entwickler) und wir definieren derzeit unseren Entwicklungsprozess einschließlich der Handhabung der Datenbankentwicklung.

Die Technologie und Werkzeugkette wir verwenden möchten:

• EF 5 (erste, weil Themen wie Sichten, Indizes usw. sind viel einfacher zu handhaben Modell zuerst, vielleicht das wir zur Datenbank ändern) SSDT (SQL Server-Datentools)
• VS 2012/TFS 2012
• MS Test für die automatisierte Einheit/Integrationstests

Der Entwicklungsprozess basiert auf Testgetriebene Entwicklung und sieht wie folgt aus:

1. Jede Funktion wird von einem Entwickler auf einem separaten Funktionszweig
2. Design und Umsetzung von Unit-Tests (= Feature-Implementierung)
3. Wenn ein entwickeltes Feature erfordert Datenbankzugriff, dann muss der Entwickler a) das EF-Modell erstellen/aktualisieren 0) b) Datenbank über EFs "Datenbank aus Modell erstellen" erstellen c) das SSDT-Projekt über Schemavergleich erstellen/aktualisieren d) Erstellen Sie die Komponententests mit einer Testinitialisierungsmethode, die neue Daten erstellt Basis und nach Testdaten für jeden Test
4. die Funktion Zweig Zweig zurück in die Integration Merge
5. Nach der Einheit/Integrationstests der CI Build führt

es nicht einige Punkte, die ich bin also in der Zusammenführung überprüft 100% sicher, wie sie (vor allem Datenbank Umgang mit Unit-Tests) zu lösen, und ich würde es begrüßen, wenn Sie mich in der richtigen Richtung setzen können:

1. Wie die Datenbankerstellung für die automatisierten Unit-Tests zu lösen:

   a) Führen Sie für jede ausgeführte Testmethode das SQL-Datenbank-Generierungsskript aus (das zuvor manuell über die SSDT-Veröffentlichungsfunktion erstellt werden kann)? Dies ist die Option, die ich bevorzugen würde, da jeder Test für jeden Test einen sauberen und konsistenten Datenbankstatus aufweist. Gibt es ein Leistungsproblem beim Erstellen der lokalen Datenbank für jeden Test?

   b) Oder verwenden Sie die Msbuild-Task "SQLPublish" oder "sqlPackage.exe"? Ich denke, dies ist keine Option, da dies eine einmalige Sache wäre und ich möchte für jeden Komponententest eine neue Testdatenbank erstellen.

   c) Oder die Testdatenbank manuell erstellen und die * .mdf-Datei im Stammverzeichnis des Quellcodeverwaltungsordners speichern und für jeden Test eine Kopie erstellen?Aber das würde ich nicht bevorzugen, weil ein Entwickler A die Datei überschreiben könnte, die Änderungen von einem anderen Entwickler B haben könnte, der seine Änderungen vorher eincheckte. Und das bedeutet, dass der Entwickler

2. Wie Testdatenerstellung für die automatisierten Unit-Tests lösen:

   a) Execute Test spezifischen SQL-Skript, das die entsprechenden Testdaten für jeden Test-Einsätze. Ich denke, das bedeutet auch, eine neue Datenbank zu erstellen, wie in Punkt 1 erwähnt. Auch dies ist meine bevorzugte Option.

   b) Oder die Verwendung von EF zum Erstellen von Testdaten scheint keine saubere Methode zu sein, da dies von der EF-Modellimplementierung abhängt, die eigentlich implizit durch die Feature-Unit-Tests getestet werden sollte.

   c) Oder verwenden Sie manuell erstellte Testdatenbankdateien. Dies würde jedoch den Entwicklungsprozess für den Entwickler komplizierter machen. Und dies könnte auch durch andere Entwickler Check-Ins überschrieben werden. das Datenbankschema wie gespeicherte Prozeduren be.The Ziel unserer Unit-Tests ist nicht zu testen und so weiter

Vielleicht ist es gut zu erwähnen, was wir von unseren Unit-Tests erwartet. Wir wollen Teile unserer Anwendungsfeatures mit "Code" Unit Tests testen, die auch als Integrationstest angesehen werden können.

Hat also jemand von Ihnen einen ähnlichen Entwicklungsprozess und was sind Ihre Erfahrungen? Irgendwelche Empfehlungen, um unseren Entwicklungsprozess zu verbessern? Gibt es Ressourcen oder Best Practices-Dokumente zur SSDT-Entwicklung? Und die wichtigste Frage für mich, wie haben Sie den automatisierten Komponententest einschließlich korrekter Datenbankhandhabungs- und Integrationstests gelöst?

Answer 1

Wenn Sie eine Datenbank benötigen, handelt es sich nicht um einen Komponententest. Für Komponententests in Kombination mit Entitäts-Framework sollten Sie einen gefälschten dbcontext verwenden.