事情从我的假存储库开始很简单，其中包含硬编码的实体列表。ASP.NET MVC单元测试 - 假库已变得笨拙
随着我的进步，我的共享虚假资料库变得臃肿。我不断地向这些列表添加新的属性和新的实体。这使得维护非常困难，而且很难看到测试正在做什么。我相信这是一种称为“General Fixture”的反模式。
在研究ASP.NET MVC单元测试中，我看到了两种方法来准备传递给控制器的存储库设备。
我很想去探索选项＃2以上之内，但我读过硬编码的假库模拟仓库并不是一个好主意，在我测试控制器对集合进行操作的场景中（例如，使用分页/排序/过滤功能），这似乎相当艰巨。
我对社会问题...
准备仓库灯具方法的工作远远超出了基本的例子是什么？
我不认为你应该只选择两个选项之一。有些情况下使用虚假的存储库会更好，并且有时候模拟会更好。我认为你应该根据具体情况评估你所需要的。例如，如果你正在编写一个UsersService的测试，需要调用返回布尔值的IUserRepository.DoesUserExist()，那么你不会使用虚假的存储库，它更容易模拟一个调用返回true或false。
Moq太棒了。
对于一个新项目的类似原因，我正在研究使用ORM（NHibernate在我的情况）。这样我就可以将它指向“内存中”的SQLLite实例（而不是SQL Server），并且它应该更容易设置/维护（我希望）。这样，如果我有要求测试特定场景（如超时等）的需求，那么我只需要模拟知识库。
如果您正在使用TDD的单元测试，请下载Rhino Mocks并使用选项＃2。
还有MOQ（http://code.google.com/p/moq/），我一直在使用＃2。我也发现这是相当笨拙和耗时的，这就是为什么我要以ORM角度来看待。 – 2010-11-23 15:35:58
大多数情况下，我们会使用特定于测试的存储库嘲讽。我从来没有见过建议不要自己这样做，我发现它的效果很好。大多数情况下，我们的存储库方法以及因此我们的模拟只返回单个模型或模型列表（而不是数据上下文），因此很容易为每个测试创建特定的数据并将其隔离到每个查询。这意味着我们可以嘲笑我们喜欢的任何数据，而不会影响同一测试中的其他测试或查询。很容易看出为什么创建数据以及测试的是什么。
我一直在团队也决定不时创建共享模拟数据。我认为这个决定通常是由于例程生成动态查询，并且模拟所有测试所需的数据导致数据库的很大一部分被复制。但是，回想起来，我可能会建议只检查结果查询，而不是从数据库返回的内容。因此，根本没有数据会被嘲笑，它需要一些代码更改。我只提到这一点，以说明如果你看不到找到一种方法来使选项2工作，也许有一种方法来重构代码，使其更具可测性。
这些都是很好的答案。自从我发布此问题以模拟单个测试的存储库并且运行良好以来，我一直在使用Moq。我相信按照您的建议使用两种方法都是有效的。我也发现创建例程生成用于模拟的数据非常有用 - 这样我就不会复制代码来创建数据，但数据也不会共享。 :) – Mayo 2010-11-30 15:53:29