ASP.NET MVC单元测试-假存储库变得很难使用

我认为你不应该只选择两个选项中的一个。有些情况下使用假存储库会更好,有些情况下模仿会更好。我认为你应该逐个评估你需要什么。例如,如果您正在为 UsersService 需要打电话给 IUserRepository.DoesUserExist() 这将返回一个布尔值,然后您就不会使用一个伪存储库,只需模拟一个返回true或false的调用就更容易了。

Moq 太棒了。

出于类似的原因,我正在研究一个新项目,使用ORM(在我的例子中是NHibernate)。这样我就可以将它指向一个“内存中”的SQLLite实例(而不是SQL Server),并且它应该更容易设置/维护(我希望如此)。这样,如果我有测试特定场景(如超时等)的需求,我只需要模拟存储库

如果您正在使用TDD的单元测试,请下载 Rhino Mocks 使用optione#2。

在大多数情况下,我们使用特定于测试的存储库模拟。我从来没有看到过不自己做这件事的建议,我发现它很有效。在大多数情况下,我们的存储库方法和模拟只返回单个模型或模型列表(而不是数据上下文),因此很容易为每个测试创建特定于每个查询的数据。这意味着我们可以模拟任何我们喜欢的数据,而不影响同一测试中的其他测试或查询。很容易看出为什么要创建数据以及它在测试什么。

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