ASP.NET MVC单元测试 - 假存储库变得难以控制

Question

我的假存储库最初只包含硬编码的实体列表，非常简单。

随着我的进展，我共享的虚假存储库变得臃肿。我不断地向这些列表中添加新属性和新实体。这使得维护变得极其困难，也很难看出测试在做什么。我认为这是一种反模式，称为“通用夹具”。

在研究ASP.NET MVC单元测试时，我看到了两种准备传递给控制器的存储库夹具的方法。

1. 创建硬编码的虚假存储库，供所有测试共享
2. 在每个测试中模拟部分存储库

我很想探索上述选项2，但我读到过不建议模拟存储库，并且在测试操作集合（即具有分页/排序/过滤功能）的控制器的情况下似乎相当令人生畏。

我的问题是...

除了基本示例之外，有哪些准备存储库夹具的方法效果好？

- Mayo

Answer 1

出于类似的原因，在一个新项目中我正在考虑使用ORM（在我的情况下是NHibernate）。这样我就可以将其指向“内存中”的SQLLite实例（而不是SQL Server），这样应该会更容易设置/维护（我希望如此）。这样，只有当我需要测试特定场景（如超时等）时，我才需要模拟存储库。

- Paul Hadfield

Answer 2

如果您正在使用单元测试进行TDD，请下载Rhino Mocks并使用选项#2。

- mxmissile

---

还有MOQ（http://code.google.com/p/moq/），我一直在用#2。我也发现它非常笨重且耗时，这就是为什么我正在研究ORM角度的原因。 - Paul Hadfield

Answer 3

我认为你不应该只选择两个选项中的一个。有些情况下使用虚假仓库会更好，有些情况下使用模拟会更好。我认为你应该根据具体情况进行评估。例如，如果你正在为一个需要调用 IUserRepository.DoesUserExist() 返回布尔值的 UsersService 编写测试，那么你不会使用虚假仓库，直接模拟调用返回 true 或 false 更容易。 Moq 很棒。

- Matt

---

这些都是很好的答案。自从我发布了这个问题以来，我一直在使用Moq来模拟单独测试的存储库，并且它运行良好。我相信按照你所建议的两种方法都是有效的。我还发现创建生成用于模拟的数据例程非常有用 - 这样我就不需要复制创建该数据的代码，但数据也不会共享。 :) - Mayo

Answer 4

大多数情况下，我们使用特定于测试的存储库模拟。我从未见过不这样做的建议，而且我发现它非常有效。对于大多数情况，我们的存储库方法以及我们的模拟仅返回单个模型或模型列表（而不是数据上下文），因此很容易为每个测试创建特定的数据并将其隔离到每个查询中。这意味着我们可以模拟任何我们喜欢的数据，而不会影响同一测试中的其他测试或查询。很容易看出为什么创建数据以及它正在测试什么。

我曾经在团队中，也决定不时创建共享模拟数据。我认为这个决定通常是因为例程生成了动态查询，并且需要模拟所有测试所需的数据导致数据库的很大一部分被复制。然而，回想起来，我可能会建议仅需要检查结果查询，而不是从数据库返回的内容。因此，根本不需要模拟任何数据，但这将需要进行一些代码更改。我提到这一点只是为了说明，如果您无法找到使选项2起作用的方法，那么也许有一种方法可以重构代码，使其更易于测试。

- Chuck