据我了解，Mocking 用于消除对另一个服务的依赖，以便您可以正确测试业务逻辑的执行，而不必担心其他服务是否工作。
但是，如果您要测试的是特定服务（即实体框架），那么针对预设测试数据库的实现式单元测试确实是唯一能告诉您任何有用信息的测试。
我错过了什么吗？模拟在我对实体框架 DAL 的测试中是否有任何位置？
【问题讨论】：
标签： c# entity-framework unit-testing mocking data-access-layer
在我看来，模拟对象与您要测试的层无关。您有一个要测试的组件，并且它具有依赖项（您可以模拟）。所以继续模拟吧。
【讨论】：
可以假设 EF 有效。您将测试与 EF 交互的代码。在这种情况下，您伪造 EF 以测试您的交互代码。
您基本上不应该测试 EF。交给微软吧。
【讨论】：
DbContext.Add() 实际上向数据库添加了一些东西。当我发现自己在测试不属于我的代码时，我只需要抓住自己 =)
你关于嘲笑的断言是正确的：
Mocking 用于消除对另一个服务的依赖，以便您 可以正确测试业务逻辑的执行，而无需 担心其他服务是否工作。
用我的话来说：单元测试背后的想法是通过单一方法测试单一代码路径。当该方法将执行移交给另一个对象时，就会产生依赖关系。当控制权传递给未模拟的依赖项时，您不再是 unit testing，而是 integration testing。
数据访问层测试通常是集成测试。正如您推测的那样，您可以利用可预测的数据集来确保您的 DAL 按预期返回结果。我不希望 DAL 有任何需要模拟的依赖项。您测试 DAL 返回的值是否符合您对数据集的预期。
以上所有内容都表明测试实体框架不是您的责任。如果您发现自己在测试 EF 的工作方式并且没有针对您的特定 DAL 实现创建测试，那么您正在编写错误的测试。换句话说：你测试你的代码，让别人测试他们的。
最后，三年前我问了一个similar question，得到的答案大大提高了我对测试的理解。虽然与您的问题不同，但我建议您通读回复。
【讨论】：
您可能会考虑的一件事是 EF 可以使用本地文件而不是您的实际存储库，您可以使用连接字符串在两者之间切换。此示例将在 AppData 文件夹或 bin 文件夹中创建 .sdf 文件（如果它是控制台应用程序）。
<connectionStrings>
<add name="SecurityContext"
connectionString="Data Source=|DataDirectory|YourDBContext.sdf"
providerName="System.Data.SqlServerCe.4.0" />
当我开始一个项目或测试时，我喜欢这个。您可以使用数据等加载数据库：EF 有一个模拟数据库供您在不接触生产数据的情况下运行测试。
【讨论】：