测试实体框架5 - 在内存数据库中是一个不错的选择

Question

我很欣赏这里有很多实体框架测试问题.但是,我遇到了Effort,它允许内存版本的数据库上下文.我想我在这方面有几个问题:

1. 使用这种方法的利弊是什么？

2. 我认为EF和内存数据库使用存储库和工作单元模式,这是否意味着我们在使用这种方法时没有实现自己的？

3. 还有其他选项,比如提供假的IDBSet,使用SQL CE或实现存储库和工作单元模式,我是否更好地使用这些技术之一？

我觉得这里选择的数量有点不知所措.我意识到可能没有银弹,但我希望得到一些指导.

谢谢

Answer 1

1) 优点：您可以测试您的 DAL 功能是否实际工作，您不需要花费大量时间来模拟存储库，只要您实例化它，您就可以更快地运行测试（大型项目需要数小时）。缺点：您实际上并没有测试实际的数据库 - 违背了集成测试的目的。更改数据库的还有配置字符串。稍后编辑：我曾经进行过大量的单元测试，现在我更喜欢垂直切片。我发现当我关心数据库时，我无论如何都需要集成测试。

就我个人而言，我是端到端测试的粉丝，因为它使测试保持集中 - 减少数量并根据规范进行实际测试。

2）uow 和存储库模式促进不同的事情。存储库封装了 DAL，并且应该从数据库提供者本身中抽象出来——通常通过工作单元模式。工作单元本质上为您提供事务访问，并且应该为您提供在测试时使用内存数据库的钩子。所以我个人并不觉得它们毫无用处。当您想要测试和模拟您的 dal 时（例如进行小型单元测试而不是验收/集成），重现模式将物有所值。没有它你能逃脱吗？可能，但拥有它的成本很小，而且还使一切变得整洁有序。除了上面所暗示的，当我最终需要实现数据库时，我确实想要一个集成测试 - 我发现这些可以很容易地从 ui 级别实现，因为我已经从外部工作/测试过。

3）不知道这不是任何人都可以回答你的问题。和他们一起玩。