测试 EF Core 应用程序

测试是几乎所有应用程序类型的一个重要关注点——它可以确保你的应用程序正常运行，并且在将来的行为发生退化时立即发现。 由于测试可能会影响代码的构建方式，因此强烈建议尽早规划测试，并确保随着应用程序的发展而获得良好的覆盖范围。 本介绍性部分简要概述了使用 EF Core 的应用程序的各种测试策略。

涉及数据库（或不涉及）

当为您的 EF Core 应用程序编写测试时，需要做出的一个基本决定是：测试是否会像应用程序那样涉及生产数据库系统，还是会使用测试替身来取代生产数据库系统。 EF Core 上下文中的两个显著测试替身示例是 SQLite 内存模式和 内存提供程序。

有关不同方法的深入比较和分析，请参阅 “选择测试策略”。 下面是一个简短的逐点摘要，可帮助你快速了解不同的选项：

• 开发人员经常避免针对其生产数据库系统进行测试，因为他们认为这是困难的或缓慢的。 这在经验中并非总是如此，我们建议给此方法一个机会： 针对生产数据库系统进行测试 提供了可靠高效地执行此操作的技术。 在任何情况下，通常都需要针对数据库编写一些测试-以确保应用程序实际适用于生产数据库，并且不涉及数据库的测试可以限制在允许你测试的内容中（请参阅下文）。
• 内存中提供者在许多重要方面无法像实际数据库那样运作。 某些功能根本无法对其进行测试（例如事务、原始 SQL.），而其他功能的行为可能不同于生产数据库（例如查询中的区分大小写）。 虽然内存中可以适用于简单受限的查询方案，但它非常有限，我们不建议使用。
  • 模拟 DbSet 进行查询是复杂而困难的，并且存在与内存方法相同的缺点；我们也不推荐这样做。
• SQLite 内存中模式 提供与生产关系数据库更好的兼容性，因为 SQLite 本身是一个全面的关系数据库。 但是，SQLite 与生产数据库之间仍存在一些重要差异，某些功能无法测试（例如 EF.Functions 中的提供程序特定的方法）。
• 对于允许对生产数据库系统的所有功能使用可靠测试替身的测试方法，可以在应用程序中引入存储库层。 这使您可以在测试中完全排除 EF Core，并彻底模拟存储库；但是，这会以一种可能具有重要意义的方式改变应用程序的架构，并且涉及更多的实现和维护成本。

延伸阅读

有关更深入的信息，请参阅 “选择测试策略”。 有关实现指南和代码示例，请参阅对比生产数据库系统的测试和无需使用生产数据库系统的测试。