DbConnection without Db using the built-in DataSet (or similar) as the source

Question

I am trying to use unit test several .NET classes that (for good design reasons) require DbConnections to do their job. For these tests, I have certain data in memory for input as input to these classes.

This in-memory data can easily be expressed as a DataTable (or a DataSet that contains this DataTable), but if another class were more suitable, I could use it.

If I could somehow get a DbConnection, which was a connection to the data in memory, then I could build my objects, make them fulfill my queries against the data in memory and ensure that their result matches expectations, Is there a way to get DbConnection for in-memory data? I have no way to install any additional third-party software for this to happen, and ideally I don’t want to touch the drive during the tests.

Answer 1

Instead of consuming DbConnection, can you use IDbConnection and mock it? We do something similar, pass the DataSet layout. DataSet.CreateDataReader returns a DataTableReader that inherits from DbDataReader.

We wrapped DbConnection in our own interface, like IDbConnection, to which we added the ExecuteReader () method, which returns a class that implements the same interfaces as DbDataReader. In our layout, ExecuteReader simply returns what the DataSet.CreateDataReader feeds.

Sounds a roundabout way, but it is very convenient to create a DataSet with a possible set of result sets. We call DataTables after the stored processes that they present the results, and our IDbConnection layout captures the right Datatable based on the process that the client invokes. DataTable also implements CreateDataReader, so we are good to go.

Answer 2

The approach I used is to create an in-memory Sqlite database. This can be done simply by pulling the System.Data.SQLite.Core NuGet package into your unit test project, you do not need to install any software anywhere else.

Although this sounds like a really obvious idea, it was only when I looked at the Dapper unit tests that I thought they used this technique themselves! See the GetSqliteConnection Method in

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

It should be remembered that if you create a sqlite database in memory and create and populate tables, you need to be careful not to close the connection before making test queries, because opening a new connection in memory will connect to the new database in memory, not to the database you just prepared carefully for your tests! For some of my tests, I use a custom IDbConnection implementation that keeps the connection open to avoid this error - for example.

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

Answer 3

TypeMock? (You would need to “install” it, though).

Be careful in believing that Data * can give you the right hooks for testing - this is a pretty worst case in general. But you say "Good reasons for design", so I'm sure everyone is covered: D