【问题标题】:MVC - Unit testing the wrong things?MVC - 单元测试错误的东西?
【发布时间】:2012-02-20 12:24:24
【问题描述】:

在为 ASP.Net MVC 项目练习一些 TDD 时,我遇到了许多场景,我正在编写测试以确保特定操作返回正确的视图或具有特定属性([ChildActionOnly] 等) . (事实上​​,我在这里找到了一些有趣的帖子,这些帖子都是关于有用的扩展方法来帮助实现这一点的)。

几年前,当我第一次接触到单元测试和 TDD 的概念时,我的重点是测试应该关注用户背后的测试逻辑——所需的特性和功能——如果你愿意的话,就是核心项目的“要求”。

我的问题是 - 如果是这种情况,是不是在检查要呈现的正确视图文件,或者是具有特定属性的操作等并没有真正包含单元测试方法的全部内容?我是出于错误的原因编写测试(即只是为了保护自己和其他同事不犯重构错误)还是这些有价值的单元测试的有效案例?

【问题讨论】:

  • 我只想指出,与其“保护”同事,不如花时间“指导”他们。你的同事可能很敏锐,只要稍加指导,每个人都会变得更好。但是,我并不是说不进行单元测试……在进行更改后进行回归测试总是很好的。

标签: c# asp.net-mvc unit-testing tdd


【解决方案1】:

如果处理程序方法可以根据某些逻辑返回两个(或更多)视图之一,那么断言正确视图的单元测试将很有用。根据逻辑插入特定属性的处理程序方法也是如此。

我是否出于错误的原因编写测试(即只是为了保护其他 同事犯了重构错误)还是这些有效的案例 有价值的单元测试?

捕捉回归错误是单元测试的好处之一,在重构时尤其有用。如果您在进行重构时无意中更改了返回的视图,这对于及早捕获非常有用 - 而不是等待仅在应用程序运行时运行的测试。

【讨论】:

    【解决方案2】:

    如果您的操作根据某些逻辑返回不同的视图(或操作结果)。写一个测试。

    如果你总是返回 View() 那么不要。

    如果您返回一个名称与您的操作名称不同的视图 - 那么您可能会争辩说编写一个测试是个好主意。

    【讨论】:

      【解决方案3】:

      这取决于。使用您的一个示例:检查一个动作是否具有特定属性是可以的,但是更好编写一个测试来验证行为是否按预期运行,如果该属性丢失,它将失败。

      也就是说,您的测试最终是一个安全网。如果它有合理的机会防止错误在未来某个时候溜进来,那么它就在做它的工作。

      如果这是一个简单的测试,开销低且将来任意中断的可能性低,那就去做吧。我宁愿测试太多也不愿太少。

      【讨论】:

        【解决方案4】:

        确实,您的测试应该是在测试您的逻辑。那不应该消失。但是,理想情况下,您应该为任何可能出错的地方编写测试。例如,确保所有需要保护的方法都具有适当的 Authorize 属性。这是一个安全测试。

        最终,您决定测试什么对您有用。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2018-12-20
          • 1970-01-01
          • 1970-01-01
          • 2017-07-10
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多