EntityFramework核心单元测试 - SQLite内存模式与InMemory提供程序

时间:2017-07-18 09:32:06

标签: c# unit-testing .net-core entity-framework-core

我正在为使用EntityFramework Core的项目编写单元测试,根据docs,我可以使用SQLite in-memory modeThe InMemory provider来近似数据库上下文。 />

文档声明SQLite in-memory mode的行为类似于关系数据库,而The InMemory provider并不总是像关系数据库那样。

据我所知,SQLite模式听起来更好,因为它的行为类似于关系型数据库,而InMemory提供程序却没有,但我想还有其他方面要考虑,否则没有人会使用The InMemory provider这听起来更糟糕。

在选择使用哪种工具之前,我应该考虑每种方法的其他优缺点吗?

3 个答案:

答案 0 :(得分:8)

如果您的唯一目的是编写单元测试,请仔细查看创建测试所需的样板代码,这可能会影响您的截止日期......我会选择让我输入更少的代码! (The InMemory provider看起来更简单。)

查看样本并决定:

...当然,您的项目将进行集成测试,对于那些您将连接到真实数据库并进行其他检查的项目。这就是为什么单元测试我的主要关注点是写时间,而不是模拟数据库的行为

答案 1 :(得分:1)

根据我的经验(我是Mig#的作者),每个数据库平台都有自己的小问题,而且它们的行为通常略有不同(例如,查看SQLiteProvider.cs的支持属性中的注释)。即使使用EF看起来一切都是从你身上抽象出来的,也可能会有微妙的差异在你的测试中给你误报或漏报。

因此,我的建议是:对要支持的实际数据库平台进行集成测试(即使创建,删除SQL Server数据库也不需要花费太多时间,并且有其他策略如何优化涉及数据库的集成测试)。对于业务逻辑,使用 smoke 测试,根本不在后台使用数据库。

这样做的另一个好处是,您可以构建类设计,使数据库访问与业务逻辑分开。

答案 2 :(得分:0)

根据文档AS 如果您对SQL Lite使用InMemory Provider,则加载关系数据时几乎没有行为差异。

  

例如如果有相关的儿童记录。使用LINQ所有的孩子   记录将自动加载,这与实际情况不符   数据库,你需要显式调用include函数。

另一种情况是连接到远程位置的数据库时I / O性能差异。

  

建议在实际应用程序性能和行为之后加入一些不会令人惊讶的实际测试