DbConnection ohne Db unter Verwendung der in-memory Datensatz (oder ähnliches) als Quelle

Question

Ich versuche, ein paar .NET-Klassen zu Unit-Test, die (für gutes Design Gründe) DbConnections benötigen, um ihre Arbeit zu tun. Für diese Tests habe ich bestimmte Daten im Speicher als Eingabe in diesen Klassen zu geben.

Das im Speicher befindlichen Daten leicht als Datentabelle ausgedrückt werden könnte (oder ein Dataset, das die Datentabelle enthält), aber wenn eine andere Klasse besser geeignet wäre, könnte ich es verwenden.

Wenn ich irgendwie magisch der Lage waren, eine DbConnection zu erhalten, die eine Verbindung zu den im Speicher befindlichen Daten repräsentiert, dann könnte ich meine Objekte konstruieren, haben sie ihre Anfragen an die im Speicher befindlichen Daten durchführen und sicherstellen, dass ihre Produktionserwartungen angepasst . Gibt es eine Möglichkeit, einen DbConnection zu im Speicher befindlichen Daten zu bekommen? Ich habe nicht die Freiheit, keine zusätzliche Software von Drittanbietern zu installieren, damit dies geschieht, und im Idealfall, ich will nicht berührt die Scheibe während der Tests.

Answer 1

Anstatt eine DbConnection verbrauchen können Sie verbrauchen IDbConnection und verspotten sie? Wir tun etwas Ähnliches passieren die mock ein DataSet. DataSet.CreateDataReader gibt eine Datatablereader, die von DbDataReader erbt.

Wir haben eingewickelt DbConnection in unserem eigenen IDbConnection-ähnliche Oberfläche zu denen haben wir eine ExecuteReader () -Methode hinzugefügt, die eine Klasse zurückgibt, die die gleichen Schnittstellen wie DbDataReader implementiert. In unserem Mock, kehrt ExecuteReader einfach das, was DataSet.CreateDataReader serviert.

Sounds Art von Kreisverkehr, aber es ist sehr bequem, ein Datensatz mit möglicherweise vielen Result aufzubauen. Wir nennen Sie die Datentabellen nach den gespeicherten Procs, die sie repräsentieren die Ergebnisse und unsere IDbConnection Mock packt die richtige Datentabelle auf der Grundlage der proc der Kunde anruft. Datatable implementiert auch CreateDataReader so sind gut, dass wir gehen.

Answer 2

Ein Ansatz, den ich verwendet habe, ist eine In-Memory-SQLite-Datenbank zu erstellen. Dies einfach durchgeführt werden kann in dem System.Data.SQLite.Core NuGet Paket an Ihrem Unit-Test-Projekt durch Ziehen, Sie müssen nicht irgendwo sonst keine Software installieren.

Auch wenn es wie eine wirklich offensichtliche Idee klingt, war es nicht, bis ich an den Dapper Unit-Tests war auf der Suche, dass ich dachte, die Technik selbst nutzen zu können! Siehe "GetSqliteConnection" -Methode in

https://github.com/ Stack / dapper-dot-net / Blob / bffb0972a076734145d92959dabbe48422d12922 / Dapper.Tests / Tests.cs

Eine Sache zu beachten ist, dass, wenn Sie einen speicherinternen sqlite db erstellen und erstellen und füllen Tabellen, die Sie brauchen nicht zu vorsichtig sein, um die Verbindung zu schließen, bevor Sie, weil Ihre Testanfragen durchführen wird eine neue In-Memory-Verbindung öffnen erhalten Sie eine Verbindung zu einer neue in-Memory-Datenbank, nicht die Datenbank, die Sie gerade sorgfältig für Ihre Tests vorbereitet! Für einige meine Tests, verwende ich eine benutzerdefinierte IDbConnection-Implementierung, die die Verbindung offen zu vermeiden diese Gefahr hält -, z. B.

https://github.com/ProductiveRage/SqlProxyAndReplay/blob/ Master / Tests / StaysOpenSqliteConnection.cs

Answer 3

TypeMock? (Sie müssten zu 'installieren' es though).

Achten Sie darauf, dass die Daten * unter der Annahme, können Ihnen die richtigen Haken zum Testen geben - es ist ziemlich der schlimmste Fall im Allgemeinen. Aber Sie sagen, Good Design Gründe, so bin ich sicher, das ist alles abgedeckt: D