【问题标题】:Mocking calls to SQL Server Stored Procedures?模拟对 SQL Server 存储过程的调用?
【发布时间】:2016-03-10 14:50:20
【问题描述】:

我正在实现一个 C# 类的接口,它的全部工作基本上只是调用一些 T-SQL 存储过程并返回数据。该接口的其他实现可能通过 Web 服务、读取文件等获取数据,因此为了测试这个特定的类,我最好模拟一个 SQL Server 数据库及其过程。

我不确定这是否可行。我见过像 RhinoMock 这样的工具用于模拟数据库tables,但由于我的代码的全部目的是与数据库对话,我可以模拟整个数据库还是有点浪费时间?理想情况下,我希望有一种方法可以透明地提供真实数据库的替代品,以便可以进行本地测试,对假数据库进行真实的存储过程调用。

【问题讨论】:

  • 你确定@inquisitive_mind 吗?这将是理想的,但是:stackoverflow.com/questions/3335162/…
  • @montewhizdoh 你可能是对的!
  • 我认为这一切都取决于。您确实不想编写最终测试代码而不是您编写的代码的单元测试。测试连接是否有效属于“我是在测试 SQL Server,还是在测试我的代码?”的灰色区域。和“我使用正确的连接字符串吗?”。最好问一下:有哪些代码路径,从存储过程传入​​和传出?测试是否与功能用例相匹配?如果您是 TDD,您希望与功能用例紧密结合 - 那时一切都会开始非常吻合..

标签: c# sql-server unit-testing stored-procedures rhino-mocks


【解决方案1】:

如果你正在构建单元测试,那么你不应该执行存储过程,你应该存根这个接口。

如果您正在构建集成测试,那么您必须让一切正常运行。

在这两种情况下,你的类都不应该直接执行,你应该有一个像 IDbHandler 这样的内部处理程序,在单元测试期间你应该模拟它,在集成测试期间你应该使用你的具体实现。

模拟的目的是验证另一方(在您的情况下为 DB)是否收到了具有预期参数的请求,但无法模拟物理组件,因此只需在您的代码和物理组件之间添加一个接口即可组件将启用这些验证。

顺便说一句,我会先进行单元测试,然后再添加集成测试。

【讨论】:

  • 因此,换句话说,不会对您创建的类进行单元测试,以实现您引入的用于抽象存储过程的接口。
  • 我不确定单元测试的价值。如果该类只是应该调用 sprocs,那么您只需要确保 sproc 名称和命名参数都与数据库中的内容匹配。似乎这是测试这个具体类的主要价值。
猜你喜欢
  • 2012-12-31
  • 1970-01-01
  • 2014-03-30
  • 2013-09-18
  • 2015-05-08
  • 2021-05-26
  • 1970-01-01
  • 2012-02-10
  • 1970-01-01
相关资源
最近更新 更多