Was ist die effektivste Möglichkeit, eine Memory-Datenbank mit Tabellen zum Testen zu erstellen?

Wenn ich dich richtig verstehe, willst du deine Tabelle für Unit Tests als In Memory Tabelle anlegen lassen?
Halte ich nicht für zielführend, da du dann die eigentlichen DB Operationen auf Dateisystem Ebene ausschließt.
Damit deckst du einen anderen Use Case ab als im produktiv System.

Auch hängt es davon ab, wie du auf die DB zugreifst.
Wenn du z.B. noch über ADO .NET gehst, müsstest du dir nur für einen Unit Test entsprechende Tabellen mit Memory Optimized Einstellung anlegen.
Bei einem OR Mapper wie EF Core könntest du dies mit dem InMemory Provider umsetzen.
Dieser ist auch nur für Tests und nicht auf Geschwindigkeit ausgelegt.
Alternativ müsstest du dir einen eigenen provider bauen.

T-Virus

Hallo ThomasE,

auch wenn auch ich das nicht für eine gute Idee halte, aber welche zugriffstechnologie oder Datenbank benutzt du denn ?

gerade bei den Datenbanken gibt ja schon unterschiedliche SQL Dialekte so, dass sich dein Problem schon nicht so einfach zu beantworten wäre.

Bei einer eigenen DAL, sollte es je nach implementierung auch einfach möglich sein, die erstellten SQL auf irgendeine Memory DB oder sogar xml oder JSON Dokumeten umzuleiten

Viele grüße
lars schmitt

@Lars Schmitt
Da er noch über ADO .NET geht, arbeitet er direkt mit dem Connection/Command Objekten etc.

@ThomasE.
Natürlich musst du für ordentliche Unit Tests eine eigene DB haben und dort alles einmal durchlaufen lassen.
Wenn du z.B. die DAL durchtest, müssen alle Operationen einmal abgedeckt werden.
Jede Methode im Unit Test sollte dann eine Operation in der DAL abdecken.

Vor jedem Test sollten die Tabellen auch einmal geleert werden, damit die Ergebnisse nicht durch Altdaten verfälscht werden.
Ziel bei Unit Tests ist auch immer eine hohe Code Coverage, damit du wirklich alles abdeckst, was abgedeckt werden muss.
Und dabei sollte man auch möglichst immer den gleichen Use Case wie das Produktiv System haben.
Erst dann können auch Fehlerfälle aus dem Produktiv System sinnvoll nachgestellt werden.

Wenn du z.B. einen Fall hast, der wegen großen Datenmengen in der DB auftritt, dann aber wegen einer anderen DB Konstruktion bei dir nicht auftritt, dann hast du deinen eigenen Test durch falsches Umfeld sabotiert.
Hier müssen dann ggf. durch Tests auf Snapshots die Szenarien nachgestellt werden können ohne Sonderschienen beim Unit Testing fahren zu müssen.
Die Umgebung muss also relativ nah am Produktiv System sein, damit die Unit Tests auch erst funktionieren.

T-Virus

Es gibt eigentlich kein Datenbank-Driver, der im Original als InMemory-Variante zur Verfügung stehen würde und sich identisch verhält.
Ich würde behaupten, dass der InMemory-Driver von EFCore mit am ähnlichsten ist; doch selbst der ist Lichtjahre vom Verhalten von MSSQL / Sqlite entfernt.

Zitat von ThomasE.:

So haben wir hier teils dynamische Kommandos, die ich gerne wie in echt, geliefert bekommen möchte, ohne fixe Datenrückgaben für jeden einzelnen Fall erstellen zu müssen.

Wenn ich Dich richtig verstehe, dann testest Du hier aber weit mehr als eine Unit.
Das geht ja eher in Richtung Integrationstest, den man ohnehin anders aufbaut.

Im Endeffekt ist das Sparen von Arbeit ja immer das Ziel.
Das Problem ist, dass Du eine "fertige InMemory-Datenbank" (also zB EFCore InMemory) eigentlich nur für Unit Testing verwendet werden kann und für Integrationstest aufgrund der Limitations total ungeeignet sind.

Je nachdem wie Du Integrationstests schneidest kann man schon so InMemory nutzen; im Falle von EFCore InMemory funktionieren aber schon einfachste Dinge nicht mehr wirklich (zB Views, Raw SQL, Transaktionen, keinerlei Support von relationalen Abhängigkeiten...), sodass der eigentliche Nutzen dahin ist.