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

本文关键字：一个 很好 选择 数据库 框架 实体 内存 测试 | 更新日期: 2023-09-27 18:15:35

我很欣赏这里已经有很多实体框架测试问题。然而，我遇到了Effort，它允许数据库上下文的内存版本。我想我有一些关于这个领域的问题:

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

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

  3. 还有其他选项，如提供假IDBSet，使用SQL CE或实现存储库和工作单元模式，我使用这些技术之一更好吗?

这里有这么多的选择，我觉得有点不知所措。我意识到可能没有灵丹妙药，但我希望能得到一些指导。

谢谢

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

1)优点:您可以测试您的DAL函数实际工作，您不需要花费大量时间来模拟存储库，如果您实例化它，您可以更快地运行测试(大型项目上几个小时)。缺点:您实际上并没有测试您的实际数据库——这违背了集成测试的意义。另外，更改数据库是一个配置字符串。我过去经常进行单元测试，现在我倾向于使用垂直切片。我发现，当我关心数据库的时候，无论如何我都需要一个集成测试。

就我个人而言，我是端到端测试的粉丝，因为它保持了测试的重点——减少了测试的数量，实际上是针对一个规范进行的测试。

2) ow和repository模式促进不同的事情。存储库封装了DAL，并且应该从db提供程序本身抽象出来——通常是通过工作单元模式。工作单元本质上为您提供事务性访问，并且应该为您提供在测试时使用内存db的钩子。所以我个人并不觉得他们是无用的。当您想要测试和模拟您的数据时(比如对于一个小单元测试而不是验收/集成)，repro模式将为自己付出代价。你能离开它吗?也许吧，但拥有它的成本很小，而且还能让一切都整洁有序。除此之外，正如上面所暗示的，当我最终需要实现db时，我确实想要一个集成测试-我发现这些可以很容易地从ui级别实现，因为我已经从外部工作/测试了。

不知道，这不是任何人都能回答你的问题。和他们一起玩

相关文章：