事情一开始很简单，我的虚假存储库包含实体的硬编码列表。
随着我的进步，我共享的虚假存储库变得臃肿。我不断地向这些列表中添加新属性和新实体。这使得维护变得极其困难，也很难看到测试在做什么。我相信这是一个名为“General Fixture”的反模式。
在研究 ASP.NET MVC 单元测试时，我看到了两种用于准备传递给 Controller 的存储库装置的方法。
- 创建在所有测试之间共享的硬编码虚假存储库
- 在每个测试中模拟部分存储库
我很想探索上面的选项 #2，但我读到模拟存储库不是一个好主意，而且在我测试在集合上运行的 Controller (即分页)的场景中，这似乎相当令人生畏/排序/过滤功能)。
我对社区的问题...
除了基本示例之外，还有哪些准备存储库装置的方法效果很好？
最佳答案
我认为您不应该只选择两个选项之一。有些情况下使用假存储库会更好，有些情况下模拟会更好。我认为你应该根据具体情况评估你需要什么。例如，如果您正在为需要调用返回 bool 值的 IUserRepository.DoesUserExist() 的 UsersService 编写测试，那么您就不会使用伪造的存储库，它更容易模拟调用以返回 true 或 false。
Moq太棒了。
关于asp.net-mvc - ASP.NET MVC 单元测试 - 虚假存储库变得笨拙，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4257433/