In-Memory-DBMS für Unit-Tests

Question

Ich suche zufriedenstellende Optionen für Einheit meiner .NET DAL-Klassen zu testen; da sie DAL-Klassen sind, greifen sie auf die Datenbank direkt ADO.NET verwenden. Derzeit ich eine Instanz einer MSSQL-Datenbank für den Test verwenden, aber frage mich, was schnellere Möglichkeiten gibt es --- da Unit-Tests müssen so schnell wie möglich, eine im Speicher laufen Lösung wäre ideal.

Ich sollte auch erwähnen, dass ich mich gebunden haben Tsql da ich immer nur eine Microsoft-Plattform einsetzen möchten.

Answer 1

Da Sie angeben:

  

Ich sollte auch erwähnen, dass ich gebunden haben   ich Tsql da ich immer nur bin   gehen werden unter Verwendung eines Microsoft   Plattform.

Dann Mit SqlServer Compact Edition kann auch für Ihre Bedürfnisse arbeiten. Es wird nicht vollständig im Speicher arbeitet aber in einem Nur-Lese-Modus betrieben werden kann (in denen keine Änderungen an die Hauptdatenbankdatei auftreten, so dass es durch mehrere Tests auf einmal verwendet werden kann)

Es gibt ein paar Fallstricke, keine gespeicherten Prozeduren unterstützt werden, einige Datentypen übersetzt werden müssen und bestimmte Datentypen haben enge Grenzen (insbesondere varchar, die nur 4000 Zeichen gehen kann) Linq to SQL ist auch nicht richtig unterstützt.

Dennoch habe ich eine SqlServer Compact Edition als Ersatz fast vollständig fällt für die richtige SQL Server-Datenbank mit guten Ergebnissen verwendet.

Answer 2

Ich habe festgestellt SQLite die beste Option sein. Obwohl, ich bin mit nHibernate, aber es ist Null Config, so dass es nur eine Sekunde einzurichten dauert. Obwohl Sie sich bewusst sein müssen, dass diese Art von Motoren der Regel ein paar Dinge fehlen müssen Sie (zB SQLite sprengt, wenn Sie Leerzeichen in Tabellennamen haben, wenn Sie ein ADO-Provider verwenden)

Zugegeben, @TopBanana Recht über einige der Probleme mit nicht eine „tatsächliche“ Datenbank. Jedoch ist ein In-Memory-RDBMS ist perfekt für diese Art von Tests, die Sie wirklich schnell ausgeführt werden sollen (zum Beispiel Check-in-Tests für inkrementelle oder CI-Builds).

Der andere große Vorteil ist, dass Sie sich um Setup keine Sorge oder abzureißen. Es ist unglaublich unproduktiv Check-in haben scheitern, weil Entwickler A Ihre Entwickler Datenbank brach; -)

Answer 3

Ich würde empfehlen, die gleiche Datenbank für die Komponententests wie für die Produktion verwendet wird. Sie nicht wirklich einige seltsame Unterschied müssen Sie in den Fuß zu schießen, wenn Sie eine Live-Ausgabe debuggen.

Wenn Sie einen Blick auf die wirklich großen Unit-Test-Suite für NHibernate haben, werden Sie sehen, dass es SQL Server verwendet (Disk-basierten) und die Tests laufen überraschend schnell. Es ist sogar noch beeindruckender bedenkt, dass es noch viel mehr Tabelle erstellen / löschen geht als die durchschnittliche Menge von Unit-Tests, die nicht, welche SQL Server ist optimiert für.

Answer 4

Ich habe gehört, dass es Software-RAM-Disk in den Fenstern zu montieren (kann mich nicht erinnern, url, sorry).

Es könnte interessant sein, Testdatenbanken auf, dass zu erstellen.

Answer 5

Ist SQL Server wirklich der Engpass für die Komponententests?

Ich meine:

1. Haben Sie Ihre Unit-Tests profiliert (mit so etwas wie SQL Profiler). Sind sie alle langsam? Sind ein paar langsam? Warum?
2. Tun Sie Ihre Unit-Tests zu viel? Ist das Setup und Teardown-Code zu schwer?
3. Wenn SQL Ihr Engpass ist, haben Sie eine Rahmen spöttisch, so dass Sie verspotten alle SQL-Aufrufe.

Answer 6

Ich hatte ähnliche Probleme mit Oracle und wir haben die folgenden:

• sorgte dafür, dass wir hatten, dass echte Unit-Tests nicht die db berührt hat, sondern verwendet Mocks für Dienstleistungen statt

• Stichwort DB-Tests, die Oracle tatsächlich benötigt im Vergleich zu den Tests, die gegen HSQLDB oder H2 oder andere In-Memory-Datenbank laufen konnte. So können wir sie separat ausgeführt werden.

• Mit den Tests, die tatsächlich verwenden Oracle Funktionen, die wir verwenden, um eine normale Oracle-Instanz, die auf einem RAM-Disk lief.

Das machte die Tests erheblich schneller.