我应该如何模拟我的数据连接
我正在尝试对我的数据访问层进行单元测试，并且正在尝试模拟我的数据连接以对我的 DAL 进行单元测试，但我在尝试模拟命令的创建时遇到了困难。我考虑过使用 IDbParameters 队列来创建参数，但单元测试要求以正确的顺序配置参数。我正在使用 MOQ 并四处寻找一些文档来引导我完成此操作，我发现很多建议不要这样做，而是为连接编写一个包装器，但我认为我的 DAL 应该是我的数据库的包装器，我不觉得我应该编写包装器......如果我这样做，我如何单元测试我的包装器与数据库的连接？通过编写另一个包装器？看起来就像是乌龟一路下来。
那么有人对单元测试/模拟的这个特定领域有任何建议或教程吗？
I'm trying to unit test my Data Access Layer and I'm in the process of trying to mock my data connectivity to unit test my DAL and I'm coming unstuck trying to mock out the creation of the commands. I thought about using a queue of IDbParameters for the creation of the parameters, but the unit tests then require that the parameters are configured in the right order. I'm using MOQ and having looked around for some documentation to walk me through this, I'm finding lots of recommendation not to do this, but to write a wrapper for the connection, but it's my contention that my DAL is supposed to be the wrapper for my database and I don't feel I should be writing wrappers... if I do, how do I unit test the connectivity to the database for my wrapper? By writing another wrapper? It seems like it's turtles all the way down.
So does anyone have any recommendations or tutorials regarding this particular area of unit testing/mocking?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在交换内存数据库方面取得了巨大成功。这使您有机会轻松地安装和拆除它。您还可以模拟连接调用，以便可以断言传入的参数，然后返回内存数据库。
I've had good success swapping an in-memory database. This gives you the opportunity to set it up and tear it down easily. You can also mock the connection call so you can assert the arguments passed in, and then return the in-memory database.
Moq 使用继承来创建模拟类 - 这种方法的缺点是您尝试伪造的类应该作为接口传递，至少不会是密封类。一种解决方案是围绕“不可模拟”类创建一个包装类并模拟该类，不幸的是，该解决方案需要大量维护。
如果您愿意购买一个模拟框架来模拟密封类，请考虑购买 Typemock Isolator 或 JustMock - 两者都可以模拟几乎任何 .NET 类和方法（包括密封类和静态方法）。
Moq uses inheritance to create a mocked class - the downside of this approach is that the class you're trying to fake should either be passed as an interface at least won't be a sealed class. One solution to is to create a wrapper class around the "un-mockable" class and mock that class instead, unfortunately this solution needs quite a lot of maintenance.
If you're willing to pay for a mocking framework that would enable you to mock sealed classes consider purchasing either Typemock Isolator or JustMock - both can mock virtually any .NET class and method (including sealed classes and static methods).
我建议不要使用模拟进行此类测试。我在 Java 中走上了这条路，但最终我总是感觉自己除了可以编写模拟语句之外几乎没有证明什么。我建议使用内存数据库或拥有每个开发人员的数据库并接受一些集成测试。
我最近转向了 .NET，这里有一个围绕 System.Data 和 System.Data 的包装器。使用了
Oracle.DataAccess，说实话，我喜欢这种方法。该包装器仅提供一个 IDatabase 接口，其中包含一系列方法，例如 DataTable ExecuteFunction(...)，这些方法提供了一种调用 Oracle 函数或过程的简单方法。此 API 的客户端看到的 System.Data 中唯一的类是 DataTable。包装器处理 IDbParameter 的所有混乱。包装器仅具有集成测试。
对实际 DAL 进行单元测试非常容易，而且编写 DAL 会更好一些。更少需要处理的可怕的样板。
DAL 提供对数据库中保存的业务功能的访问。 DB 包装器剥离了样板代码（并允许您模拟它）。
不。接受有些事情是集成测试。
I'd recommend against using mocks for this type of testing. I went down this path with Java and it always ended with me feeling that I have proved little except that I can write mocking statements. I would recommend either using in-memory database or having a per-developer database and accept some things are integration tests.
I moved to .NET reciently and here a wrapper around
System.Data&Oracle.DataAccessis used and to be honest, I love this approach.The wrapper simply provides an IDatabase interface with a bunch of methods like
DataTable ExecuteFunction(...)which offer an easy way to call a oracle function or procedure. The only class from System.Data seen by the clients of this API is DataTable. The wrapper handles all the messing about with IDbParameter. The wrapper only has integration tests.Unit testing the actual DAL is very easy, plus writing the DAL gets that little bit nicer. Less horrid boilerplate to deal with.
The DAL provides access to business functions held in the database. The DB wrapper strips away boiler plate code (and allows you to mock it).
Don't. Accept that some things are integration tests.