我将为新的MVC4应用重新编码一套单元测试。由于EF数据项目中的几乎所有代码都是直接从VS2012 EF逆向工程工具生成的代码复制而来的，因此，我决定跳过该应用程序此部分中的单元测试，除非可以通过某种方式自动生成它们。我这里没有业务逻辑，我想首先集中精力确保业务方面更好的质量检查。但是，我想知道第一个是TDD，第二个是总体上的单元测试。
假设我不必或不想模拟数据库。以前，我经常对测试数据库副本进行单元测试非常满意，但是使用更常规的本地滚动ORM。
因此，我首先从实例化驱动的DbContext的测试开始，然后派生DbContext直到该测试通过。然后，测试实例化一个实体，并创建一个实体，然后测试这些实体的DbSet，该测试还将包括检查是否创建了表。一切仍然是好事，即使不是费力的工作，但是我一想到甚至暗示为所有实体测试我的流利的映射类的提示，我的脑袋就会plo之以鼻。现在怎么办？
针对数据库的测试不是单元测试-它是集成测试，并且集成测试通常不遵循单元测试的粒度。为什么不进行单元测试？由于单元测试只测试一个自包含的单元-所有外部依赖项都是伪造的。当您的测试跨越单元代码和数据库时，它也会测试依赖关系=它是集成测试。
所有与EF相关的代码都应通过集成测试进行测试。对Microsoft的代码进行单元测试没有任何意义。例如，您关于映射的问题。正确的映射单元测试的作用类似于：
现在您可以对要在该实体中映射的每个属性重复类似的测试。
这显然是应该已经起作用的框架代码-这些测试应该由开发框架的人员完成。
在您的情况下，对本地数据库进行简单的集成测试，它将尝试加载，保存，更新和删除实体，并声明您对这些操作的期望。如果映射中的任何错误，则至少其中一项测试将失败。