DbConnection 不带 Db，使用内存中的 DataSet（或类似的）作为源
我正在尝试对一些 .NET 类进行单元测试，这些类（出于良好的设计原因）需要 DbConnections 来完成其工作。 对于这些测试，我在内存中有某些数据可以作为这些类的输入。
内存中的数据可以很容易地表示为 DataTable（或包含该 DataTable 的 DataSet），但如果另一个类更合适，我可以使用它。
如果我能够以某种方式神奇地获得一个表示与内存中数据的连接的 DbConnection，那么我就可以构造我的对象，让它们对内存中数据执行查询，并确保它们的输出符合预期。 是否有某种方法可以获取内存数据的 DbConnection？ 我没有安装任何其他第三方软件来实现此目的的自由，理想情况下，我不想这样做在测试过程中触摸磁盘。
I'm trying to unit test a few .NET classes that (for good design reasons) require DbConnections to do their work. For these tests, I have certain data in memory to give as input to these classes.
That in-memory data could be easily expressed as a DataTable (or a DataSet that contains that DataTable), but if another class were more appropriate I could use it.
If I were somehow magically able to get a DbConnection that represented a connection to the in-memory data, then I could construct my objects, have them execute their queries against the in-memory data, and ensure that their output matched expectations. Is there some way to get a DbConnection to in-memory data? I don't have the freedom to install any additional third-party software to make this happen, and ideally, I don't want to touch the disk during the tests.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用 IDbConnection 并模拟它，而不是使用 DbConnection 吗？ 我们做了类似的事情，向模拟传递一个数据集。 DataSet.CreateDataReader 返回一个继承自 DbDataReader 的 DataTableReader。
我们将 DbConnection 包装在我们自己的类似 IDbConnection 的接口中，并添加了一个 ExecuteReader() 方法，该方法返回一个实现与 DbDataReader 相同接口的类。 在我们的模拟中，ExecuteReader 只是返回 DataSet.CreateDataReader 提供的内容。
听起来有点迂回，但是构建一个可能包含许多结果集的数据集非常方便。 我们根据代表结果的存储过程来命名数据表，并且我们的 IDbConnection 模拟根据客户端调用的过程获取正确的数据表。 DataTable 还实现了 CreateDataReader，所以我们可以开始了。
Rather than consume a DbConnection can you consume IDbConnection and mock it? We do something similar, pass the mock a DataSet. DataSet.CreateDataReader returns a DataTableReader which inherits from DbDataReader.
We have wrapped DbConnection in our own IDbConnection-like interface to which we've added an ExecuteReader() method which returns a class that implements the same interfaces as DbDataReader. In our mock, ExecuteReader simply returns what DataSet.CreateDataReader serves up.
Sounds kind of roundabout, but it is very convenient to build up a DataSet with possibly many resultsets. We name the DataTables after the stored procs that they represent the results of, and our IDbConnection mock grabs the right Datatable based on the proc the client is calling. DataTable also implements CreateDataReader so we're good to go.
我使用的一种方法是创建内存中的 Sqlite 数据库。 只需将 System.Data.SQLite.Core NuGet 包拉入单元测试项目即可完成此操作，无需在其他任何地方安装任何软件。
虽然这听起来是一个非常明显的想法，但直到我查看 Dapper 单元测试时，我才想到自己使用该技术！ 中的“GetSqliteConnection”方法
请参阅https:// github.com/StackExchange/dapper-dot-net/blob/bffb0972a076734145d92959dabbe48422d12922/Dapper.Tests/Tests.cs
需要注意的一件事是，如果您创建内存中的 sqlite 数据库并创建和填充表，您需要小心，在执行测试查询之前不要关闭连接，因为打开新的内存连接将为您提供到新内存数据库的连接，而不是 您刚刚为测试精心准备的数据库！ 对于我的一些测试，我使用自定义 IDbConnection 实现来保持连接打开以避免这个陷阱 - 例如。
https://github.com/ProductiveRage/SqlProxyAndReplay/blob/master/Tests /StaysOpenSqliteConnection.cs
An approach that I've used is to create an in-memory Sqlite database. This may be done simply by pulling in the System.Data.SQLite.Core NuGet package to your unit test project, you don't need to install any software anywhere else.
Although it sounds like a really obvious idea, it wasn't until I was looking at the Dapper unit tests that I thought to use the technique myself! See the "GetSqliteConnection" method in
https://github.com/StackExchange/dapper-dot-net/blob/bffb0972a076734145d92959dabbe48422d12922/Dapper.Tests/Tests.cs
One thing to be aware of is that if you create an in-memory sqlite db and create and populate tables, you need to be careful not to close the connection before performing your test queries because opening a new in-memory connection will get you a connection to a new in-memory database, not the database that you just carefully prepared for your tests! For some of my tests, I use a custom IDbConnection implementation that keeps the connection open to avoid this pitfall - eg.
https://github.com/ProductiveRage/SqlProxyAndReplay/blob/master/Tests/StaysOpenSqliteConnection.cs
类型模拟？ （不过，您需要“安装”它）。
请小心假设 Data* 可以为您提供适当的测试挂钩 - 一般来说，这是最糟糕的情况。 但你说良好的设计原因，所以我确信这一切都涵盖了：D
TypeMock? (You would need to 'install' it though).
Be careful assuming that Data* can give you proper hooks for testing - its pretty the worst case in general. But you say Good Design Reasons, so I'm sure that's all covered :D