事情开始时,我的假存储库包含硬编码的实体列表. 随着我的进步,我的共享虚假存储库变得臃肿.我不断向这些列表中添加新属性和新实体.这使得维护非常困难,并且也很难看出测试正在做
随着我的进步,我的共享虚假存储库变得臃肿.我不断向这些列表中添加新属性和新实体.这使得维护非常困难,并且也很难看出测试正在做什么.我相信这是一个名为“General Fixture”的反模式.
在研究ASP.NET MVC单元测试时,我已经看到了两种方法来准备传递给控制器的存储库夹具.
>创建在所有测试中共享的硬编码虚假存储库
>在每次测试中模拟部分存储库
我很想探索上面的选项#2,但我已经读过,模拟存储库并不是一个好主意,在我正在测试对集合进行操作的控制器(即使用分页/排序/过滤能力).
我向社区提出的问题……
准备存储库装置的哪些方法远远超出了基本的例子?
我不认为你应该只选择两个选项中的一个.有些情况下使用假存储库会更好,并且有些情况下,模拟会更好.我认为您应该根据具体情况评估您的需求.例如,如果您正在为需要调用返回布尔值的IUserRepository.DoesUserExist()的UsersService编写测试,那么您将不会使用虚假存储库,它更容易模拟调用以返回true或false.Moq真棒.