ASP.NET MVC单元测试 - 假存储库变得笨拙

Question

我的假存储库包含硬编码的实体列表，事情很简单。

随着我的进步，我的共享虚假存储库变得臃肿。我不断向这些列表中添加新属性和新实体。这使得维护非常困难，并且也很难看出测试正在做什么。我相信这是一种名为“General Fixture”的反模式。

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

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

我很想探索上面的选项＃2，但我已经读过，模拟存储库并不是一个好主意，在我正在测试对集合进行操作的控制器（即使用分页）的情况下，它似乎相当令人生畏/排序/过滤功能）。

我向社区提出的问题......

准备存储库装置的哪些方法远远超出了基本的例子？

Answer 1

由于类似的原因，我正在研究使用ORM（在我的情况下是NHibernate）。这样我可以将它指向“内存中”SQLLite实例（而不是SQL Server），它应该更容易设置/维护（我希望）。这样，如果我需要测试特定场景（例如超时等），我只需要模拟存储库

Answer 2

如果您使用TDD的单元测试，请下载Rhino Mocks并使用选项＃2。

Answer 3

我认为你不应该只选择其中一个选项。有些情况下使用假存储库会更好，并且有些情况下，模拟会更好。我认为您应该根据具体情况评估您的需求。例如，如果您正在为需要调用返回布尔值的UsersService的{​​{1}}编写测试，那么您将不会使用虚假存储库，只需将Mock调用返回true或更简单假的。

Moq太棒了。

Answer 4

在大多数情况下，我们使用特定于测试的存储库模拟。我从未见过不自己这样做的建议，我发现它很有效。在大多数情况下，我们的存储库方法以及我们的模拟只返回单个模型或模型列表（而不是数据上下文），因此很容易创建特定于每个测试的数据并与每个查询隔离。这意味着我们可以模拟我们喜欢的任何数据，而不会影响同一测试中的其他测试或查询。很容易理解数据创建原因和测试内容。

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