如何使遗留系统严重依赖实体框架更可测试？

Question

我们有一个相当大的系统（~1m行），它严重依赖于Entity Framework 6.这意味着我们的DbContext被传递并在任何地方使用。

我们还有许多使用实际SQL Server数据库的“单元”测试。每台运行测试的计算机都有一个专用数据库，在运行每个测试之前，它会被擦除并设置所需的数据。

在速度，可维护性，易用性等方面，这当然不是理想的。

我的最终目标是让我们所有的单元测试（~5k测试）不使用实际的数据库，而是使用某种类型的模拟。我知道这个过程并不容易，但我也希望尽可能减少痛苦。

如何让我的测试速度更快，单位范围更广？

Answer 1

这里只有一个选项，那就是制作一个内存系统。内存中令人遗憾的部分是它与实体框架并不完全融合，就像它一样。

实体框架的所有模拟都建议使用已经设置的模拟数据库。

所以好消息是你可以自己在记忆中做到这一点！坏消息是你可以在内存中自己做。

您将不得不创建实体框架的镜像实现，该实现仅适用于内存信息集。在许多方面，这类似于内存缓存系统中的事件驱动，并且您将在内存中创建用于模拟的自定义实现的好处是，您可以轻松地将其移植到支持缓存数据库信息并允许接口为询问这些信息。

这将公开实时数据的事件驱动推送技术（SignalR）等功能。这也需要很多时间。如果实现内存模拟实体框架所需的开发时间少于因等待测试在模拟数据库中完成而丢失的时间，那么它可能是值得的。

Answer 2

  

我们还有许多使用实际SQL Server数据库的“单元”测试。每台运行测试的计算机都有一个专用数据库，在运行每个测试之前，它会被擦除并设置所需的数据。

     

在速度，可维护性，易用性等方面，这当然不是理想的。

     

我的最终目标是让我们所有的单元测试（~5k测试）不使用实际的数据库，而是使用某种类型的模拟。我知道这个过程并不容易，但我也希望尽可能减少痛苦。

我不同意你的结论。我建议您保留现有的专用测试数据库，我实际上认为使用实际数据库进行测试是一个很好的主意，因为它会揭示任何数据层问题，例如，如果有人对数据库模式进行了更改而没有反映在您的数据库模式中EF实体类。 EF本身经过了相当好的测试，因此在我个人看来，对EF生成的类进行代码覆盖是一个愚蠢的错误，实体类和数据库之间的脱节可能是事情可以（并且将会）去的第一个领域错。

我理解您使用此方法时的性能问题，当然可能存在潜在的优化，例如在运行每个测试之前不重置数据库（可能让测试假设数据库在启动之前处于已知的“良好状态”）并且仅在测试套件完成后重置它。