0

我即将为新的 MVC4 应用程序重新编写一套单元测试。因为我在 EF 数据项目中的几乎所有代码都是直接从 VS2012 EF 逆向工程工具生成的代码中复制而来的，所以我决定在应用程序的这一部分中跳过单元测试，除非我能以某种方式自动生成它们。我在这里没有业务逻辑，我想首先集中精力确保业务方面更好的质量保证。但是，我想知道第一个 TDD 是如何进行的，其次，这里只是一般的单元测试。

假设我还不需要或不想模拟数据库。我以前经常对测试数据库副本进行单元测试，但使用更传统的、家庭滚动的 ORM。

那么，我是否从一个实例化我驱动的 DbContext 的测试开始，然后派生一个 DbContext 直到该测试通过。然后，测试实例化实体并创建实体，继续测试这些实体的 DbSet，该测试还将包括检查表是否已创建。一切仍然很好，如果不是非常费力的话，但是当我开始考虑为我的所有实体测试我的流利映射类时，我的头就会爆炸。现在怎么办？

4

1 回答 1

2

针对数据库的测试不是单元测试——它是集成测试，集成测试通常不遵循单元测试的粒度。为什么不是单元测试？因为单元测试测试单个自包含单元 - 所有外部依赖项都是伪造的。当您的测试跨越您的单元代码和数据库时，它也会测试依赖关系=它是集成测试。

所有依赖 EF 的代码都应该通过集成测试进行测试。对微软的代码进行单元测试是没有意义的。例如你关于映射的问题。映射的正确单元测试执行以下操作：

  • 准备：使用您的实体映射配置准备编译模型
  • 执行：从编译模型创建 DbContext 并从上下文中获取元数据工作空间
  • 验证：断言元数据上下文包含您的映射实体

现在，您可以对要在该实体中映射的每个属性重复类似的测试。

这显然是应该已经工作的框架代码——这些测试应该由开发框架的人来完成。

在您的情况下，对本地数据库进行简单的集成测试，该数据库将尝试加载、保存、更新和删除实体，并断言您对这些操作的期望。如果映射中有任何错误，这些测试中至少有一个会失败。

于 2012-07-02T13:41:49.677 回答