0

我现在发现自己有一个 EF Code First DbContext 和实体类，我现在更愿意将其排除在单元测试之外，因为 Code First 不是关键要求，我不会对 DB First 生成的类进行单元测试，但除此之外我有一个存储库，它们都是一个模板的复制和粘贴副本，然后是一些视图模式和控制器。

我现在想采用 TDD 方法作为前进的方向，并为非纯（仅属性）DTO 的视图模型和我的操作方法添加单元测试。我是否朝着正确的方向前进，并牢记正确的覆盖范围？那么，我如何对动作进行单元测试呢？一些指向资源和教程的指针会很好。

4

1 回答 1

1

理想情况下，在完美的 TDD 环境中，您将对代码中的所有内容进行测试 - 但有些人可能认为这是教条主义的，您认为不需要测试您的代码优先生成的数据库，所以不要这样做： ) . 你是开发者，做你想做的事。

我理解您对上述内容的感受，但是如果您想以真正的 TDD 风格进行开发，您需要在编写任何代码之前编写一个测试，然后编写代码以获得测试的“绿灯​​”。

基本工作流程如下（从您想要添加到应用程序中的任何内容开始DBContext）

  1. 意识到您的 MVC 应用程序需要一个新功能
  2. 编写一个失败的测试（因为此时没有实际的代码）
  3. 编写您想要添加到应用程序的新功能
  4. 运行你的测试，如果测试通过，继续 5，如果失败，编辑代码并重复 4
  5. 根据需要重构并重新运行测试以确保一切通过

你会有很多测试，但只要你勤奋地维护这些测试，你就会有一个非常完善的应用程序。

在将 TDD 与 MVC（或可能的任何开发架构）一起使用时，请记住以下几点：

  • 经常运行你的测试
  • 确保您的测试在过去一次通过后全部通过（听起来很明显，但有些人很疯狂）
  • 确保您可以轻松快速地运行测试，最好单击一两次即可运行测试。这将允许您更轻松地频繁运行它们 - 这就是测试的目的。
  • 坚持下去，很容易变得懒惰，只是说，“是的，我知道这部分会起作用，不需要测试它”，但是当你在几周/几个月/几年后查看该代码时，你不会由于与它密切相关，您可能会不小心更改某些内容并运行项目的测试（因为它是使用 TDD 流程开发的）并注意到一切都通过了。但是，由于没有对您更改的部分进行测试，因此您没有证据表明代码全部按计划工作。这听起来很简单，但可以将其视为可能导致其他问题的被遗忘的“破窗”。

至于专门为 MVC 操作编写测试，我强烈推荐来自 MSDN 的本教程和这本书： Freeman 和 Sanderson 的Pro ASP.NET MVC 3 Framework（这是 MVC3 的一个整体很好的资源，包括 MVC3 的 TDD）。

于 2012-06-28T11:54:34.343 回答