【问题标题】：In Memory database vs Moqing framework in .NET Core [closed]在.NET Core中的内存数据库与Moqing框架[关闭]
【发布时间】：2018-05-03 11:50:40
【问题描述】：
我们将在下一个项目中实施 TDD 方法。所以我一直在研究在 ASP.NET Core 中使用 NUnit 进行单元测试。因为我是新手，所以我对一些事情感到困惑。因此，我想与您分享这些问题，以便根据专家意见做出决策。
- Mocking 数据库和 In-Memory 数据库的优缺点是什么？
- 在什么情况下应该使用 Mocking，在什么情况下应该使用 InMemory 数据库提供程序？
- 哪种方法更好，使用 InMemory 还是使用 Mocking？
- 我们可以在同一个项目中同时实施这两种方法吗？
- 对于集成测试，我们应该使用 mocking 还是 In Memory？
- 在单元测试中使用 In-Memory 数据库是否更好？
- 在测试业务层时，我们应该使用 Mocking 还是 In-Memory 数据库？
- 在测试 MVC 控制器时，我们应该使用 Mocking 还是 In-Memory 数据库？
请帮助我找到这些问题的答案。可能是，有些问题是相似的，但是，为了让你们更好地理解，我不想删除它们。谢谢。
【问题讨论】：
-
请编辑问题以将其限制为具有足够详细信息的特定问题，以确定适当的答案。避免一次问多个不同的问题。请参阅How to Ask 页面以帮助澄清此问题
标签：
unit-testing
asp.net-core-mvc
tdd
moq
in-memory-database
【解决方案1】：
对于这一切有各种各样的意见，所以我认为你很难得到任何明确的答案。也就是说，我个人认为内存数据库非常适合用于单元测试。有些人认为，当您在 EF 中使用内存数据库时，它在技术上是集成测试，因为您实际上涉及到所有 EF 机器。但是，我有两点反对该理论：1）它是内存中的，因此实际上不是一个现实的集成测试（因为您显然不会在生产中使用内存数据库）和 2）两者之间几乎没有区别并创建一个复杂的模拟，从一些内存集合中返回数据。
因此，我认为在 EF 中使用内存数据库提供程序进行单元测试就可以了。它只是为您节省了必须构建模拟的时间，这对于模拟像 EF 这样的 ORM 可能非常重要。但是，它也有自己的包袱，所以我只建议您在测试本质上依赖 EF 的方法时这样做。例如，如果您将 EF 上下文注入到一个类中，并且您正在测试一个依赖于它的方法，那么可以，使用内存提供程序并注入一个实际的上下文。但是，如果您只是在测试一个对传入的任意数据集进行操作的方法，那么只需为此使用文本夹具，而不是引导 EF 上下文，只是将一些数据拉出到喂给方法。
就集成测试而言，它实际上取决于您要测试的内容。即使根据定义，集成测试涉及多个不同的组件，您仍然应该尽可能地限制测试的范围。因此，如果您正在执行诸如测试操作结果之类的操作，那么您将为此使用内存数据库，因为您关心的是结果，而不是与数据库的连接是否正确。但是，如果您有一个实际上是在查看与数据库相关的集成的集成测试，那么您最好模拟一个真实的连接以确保您的连接字符串之类的东西是正确的。不过，在大多数情况下，是的，您应该使用内存提供程序进行大多数事情的集成测试。