有人有使用 SQLite 编写集成测试的经验吗？答案

【问题标题】：Does anybody have experience of using SQLite to write integration tests?有人有使用 SQLite 编写集成测试的经验吗？
【发布时间】：2011-08-05 08:05:50
【问题描述】：

我们在项目中使用 MVC、Entity Framework 4.1 Code First、SQL Server。

请分享您的经验：您如何对数据服务层进行单元测试？数据服务层是指应该由 MVC 控制器运行的服务，这些控制器内部具有某种 DbContext 派生类声明，因此它们依赖于这个 EF DbContext，并封装了一些业务/数据逻辑来获取和存储数据。

在阅读了几篇文章和帖子后，我倾向于使用单独的数据库来构建单元/集成测试，并且我更喜欢使用内存中（如 SQLite）而不是 SQL Compact。但是我什至不确定这是否可能，如果您有这样的经验，请分享几行代码来展示您如何实现这一目标。

【问题讨论】：

标签： unit-testing entity-framework entity-framework-4 entity-framework-4.1

【解决方案1】：

单元测试意味着测试单元=没有数据库，没有外部依赖，只测试单个可测试单元。一旦你想涉及数据库，你就不再进行单元测试——你正在做集成测试。

我写了多个关于依赖 EF 的代码的单元测试/集成测试的答案。最后一个是here。因此，如果您的服务层在上下文中创建 linq 查询，您将无法可靠地对它们进行单元测试。您需要集成测试。

我会使用与您希望在实际代码中使用的数据库相同的数据库。为什么？因为数据库提供之间的映射和行为以及 LINQ 的实现可能不同。同样在 SQL 服务器的情况下，您可以使用special EF features，它不必在 SQLite 中可用。另一个原因是我上次检查时，SQLite 的提供程序不支持数据库删除、重新创建等，这是人们通常希望用于集成测试的东西。解决方案可以是Devart provider。

【讨论】：

对，我说的是集成测试。我提到单元测试只是为了让您知道这个集成测试应该在某种程度上取代服务级别的单元测试，我的意思是我不会同时做这两件事。感谢您提供有关 SQL Lite 的信息。
我想补充一下我之前的评论：我对基于文件系统（不是内存）数据库的关注是性能。单元测试是我们构建过程的一部分，大量的数据库操作可能会损害构建的整体性能
@YMC：如果你想使用数据库测试应用程序，你总是需要集成测试。唯一的问题是你需要多少。您想测试您的应用程序吗？因此，付出代价并使用较慢的构建或设置构建服务器，并让构建和集成测试在不同的机器上执行。
我只是假设使用 SQLite 和它的内存提供程序可以将单元测试性能提高几倍，同时它们是真正的集成测试，这意味着它们也会测试 LINQ->SQL 映射。我知道它的独立提供程序具有自己的 SQL 脚本生成引擎，可能与生产环境中的 SQL Server 提供程序不同，但我希望它可以帮助我们发现大多数潜在的映射问题。

【解决方案2】：

我根本不使用单独的数据库。事实上，我的单元测试根本不使用数据库。

我的策略是为数据库实体创建 IEnityRepository 接口（将实体替换为实际名称）。然后我将它们传递给我的控制器的构造函数。

在单元测试期间，我只是使用一个 Mocking 库来传递我需要的存储库的模拟实现，并返回一组我可以在单元测试中使用的已知数据。

【讨论】：

我也想过。但是我更喜欢集成测试，因为有两个原因：1）您更有可能发现 LINQ 表达式 -> 使用真实数据库而不是模拟的 SQL 脚本映射问题 2）您必须添加额外的层以从您想要应用的数据服务中隐藏 DbContext单元测试