Nein, alles, was dapper ist, sind Erweiterungsmethoden auf der IDbConnection Klasse.
Es gibt keine InMemory-Implementierung dafür (IDbConnection) (die SQL-Strings versteht).
Ihre beste Wette jedoch, wenn Sie es völlig autonom ausführen möchten, wäre es, einen neuen SQL-Server für jedes Mal hochzufahren, wenn Sie Komponententests ausführen. Dies kann leicht mit dem Docker Bild durchgeführt werden, die Microsoft für sqlserver gemacht hat: https://hub.docker.com/r/microsoft/mssql-server-linux/
oder ...
Oder wandern zu Entity Framework, sie ermöglichen es Ihnen, Unit-Test gegen einen In-Memory-Sicherungsspeicher.
warum?
Dapper enthält nur einige nützliche Funktionen zum Generieren von SQL. Es abstrahiert keineswegs von SQL. Und SQL ist nur einfacher Text für C# -Code. es analysiert es nicht und führt es auch nicht aus. Daher können Sie Ihren sql/dapper-Code nicht testen, ohne eine Datenbank dahinter zu verwenden.
Entity-Framework macht es anders. Es versucht, alles, was Sie in einer Datenbank tun möchten, in C# -Code/Abstraktion (zB die IDbCollection) zu machen. Dann machen sie 1 Implementierung, die SQL-Code generiert, und eine Implementierung, die speicherinternen Speicher verwendet. Auf diese Weise können Sie Ihren Code testen.
Microsofts Lösung
Microsoft wirbt oft die Repository Pattern verwenden. Dies ist im Grunde ein teures Wort, um alle Ihre Datenbankaufrufe/-Befehle in eine separate Klasse zu abstrahieren und diese Klassen zu verbinden, und die Schnittstellen überall im Code zu verwenden (mit Abhängigkeitsinjektion). Jetzt können Sie Komponententests schreiben, die Ihren gesamten Code für die SQL-Abfragen testen. Für diese Schnittstelle führen Sie einen Mock aus, um zu testen, ob die Methode tatsächlich aufgerufen wird.
Hrm. Wenn ich mit einer externen Datenquelle gehen muss, die dies fast in den Bereich des Integrationstests und nicht des Komponententests drängt. Wenn das der Fall ist, werde ich sehen, was mit etwas wie SqlLite (http://stackoverflow.com/a/38630232/3691973) statt einer vollständigen SQL-Datenbank, die für jeden Testlauf zurückgesetzt werden müsste, getan werden kann. Ich werde dies als die Antwort für den Moment markieren, da es noch keinen ganz internen Weg gibt, dies zu tun. Hoffentlich wird dies einfacher, wenn DataSets zur Verfügung gestellt werden. Wie es scheint, scheint dies ein signifikantes Problem bei der Verwendung von Dapper + .net-Core. – Necoras
@Necoras testing sql ist grundsätzlich immer ein Integrationstest. aber ja, sql lite ist eine gute alternative. Aber wisse, dass du mit sql quiet heavenlh Features verwenden kannst, die in sqlLite nicht unterstützt werden oder sich anders verhalten, und dass du dadurch keine korrekte Sicht auf die Produktionsumgebung erhältst. –
Ja, ich bin mir bewusst, dass es etwas anders als unser Produktionssystem funktionieren könnte, weshalb ich auf eine direktere Darstellung im Speicher gehofft habe.Zum Glück ist der Großteil unseres Sql ziemlich einfach. Hoffentlich gibt es in unseren Anwendungsfällen keine signifikanten Divergenzprobleme zwischen SqLite und Sql Server. – Necoras