DbConnection senza Db utilizzare in memoria DataSet (o simile) come sorgente

Question

Sto cercando di unit test un paio di classi .NET che (per motivi Good Design) richiedono DbConnections a fare il loro lavoro. Per questi test, ho alcuni dati nella memoria per dare come input per queste classi.

Che in memoria i dati potrebbero essere facilmente espresse in un DataTable (o un DataSet che contiene quel DataTable), ma se un'altra classe fosse più appropriato potrei usarlo.

Se io fossi in qualche modo magicamente in grado di ottenere un DbConnection che rappresentava una connessione ai dati in memoria, quindi ho potuto costruire i miei oggetti, li hanno eseguire le loro domande a fronte dei dati in memoria, e garantire che la loro produzione abbinato aspettative . C'è qualche modo per ottenere un DbConnection ai dati in memoria? non ho la libertà di installare alcun software aggiuntivo di terze parti per rendere questo accada, e idealmente, io non voglio toccare il disco durante le prove.

Answer 1

Invece di consumare un DbConnection si può consumare IDbConnection e beffe di esso? Facciamo qualcosa di simile, passare il finto un DataSet. DataSet.CreateDataReader restituisce un DataTableReader che eredita da DbDataReader.

Abbiamo avvolto DbConnection nella nostra propria interfaccia IDbConnection simile a cui abbiamo aggiunto un metodo ExecuteReader (), che restituisce una classe che implementa le stesse interfacce come DbDataReader. Nel nostro finto, ExecuteReader ritorna semplicemente ciò DataSet.CreateDataReader serve.

Suoni sorta di rotonda, ma è molto comodo per costruire un DataSet con forse molti di risultati. Abbiamo il nome del DataTable dopo le stored procedure che rappresentano i risultati di, e la nostra finta IDbConnection afferra il diritto Datatable sulla base del proc il cliente sta chiamando. DataTable implementa anche CreateDataReader quindi siamo a posto.

Answer 2

Un approccio che ho usato è quello di creare un database SQLite in memoria. Questo può essere fatto semplicemente tirando nel pacchetto System.Data.SQLite.Core NuGet al progetto unit test, non è necessario installare alcun software in qualsiasi altro luogo.

Anche se suona come un davvero evidente idea, non è stato fino stavo guardando i test di unità Dapper che ho pensato di utilizzare la tecnica di me stesso! Vedere il metodo "GetSqliteConnection" in

https://github.com/ StackExchange / Dapper-dot-net / blob / bffb0972a076734145d92959dabbe48422d12922 / Dapper.Tests / Tests.cs

Una cosa da essere consapevoli è che se si crea uno sqlite db in memoria e creare e popolare le tabelle, è necessario fare attenzione a non chiudere la connessione prima di eseguire le query di prova, perché l'apertura di una nuova connessione in memoria sarà ottenere una connessione a un nuovo database in memoria, non il database appena preparato con cura per i test! Per alcuni dei miei test, io uso un'implementazione IDbConnection personalizzato che mantiene la connessione aperta per evitare questa trappola -. Ad esempio

https://github.com/ProductiveRage/SqlProxyAndReplay/blob/ master / Test / StaysOpenSqliteConnection.cs

Answer 3

TypeMock? (Si avrebbe bisogno di 'installazione', però).

Fare attenzione assumendo che i dati * può dare appositi ganci per il test - la sua piuttosto il caso peggiore in generale. Ma che dici buone ragioni di progettazione, quindi sono sicuro che è tutto coperto: D