【问题标题】:When Testing your MVC-based UI, how much of the test setup do you make common?在测试基于 MVC 的 UI 时,您常用的测试设置有多少?
【发布时间】:2010-09-08 18:14:49
【问题描述】:

我正在尝试测试一个简单的基于 WebForms (asp.net) 的 UI,并遵循 MVP 模式以使我的 UI 更具可测试性。

当我遵循后端算法的 TDD 方法时,我发现有一些单元测试重构是本着 DRY 原则(不要重复自己)的精神发生的。当我尝试使用 Rhino Mocks 将其应用于 UI 以验证我的交互时,在设置视图或模型期望时,我在 Controller 测试中看到了许多共性。

我的问题是:如果有的话,您通常会在多大程度上进行这种重构?我很想知道其他 TDDer 如何测试他们基于 MVC/MVP 的 UI。

【问题讨论】:

    标签: unit-testing model-view-controller user-interface tdd mvp


    【解决方案1】:

    我不会像标准代码那样重构测试。当您将事物重构为通用基类、辅助方法等时,测试开始变得更加模糊。测试本身应该足够清晰。

    DRY 不是测试问题。

    也就是说,有许多管道工作是常见的,应该抽象出来。

    【讨论】:

      【解决方案2】:

      我使用 MVP,在我的测试中,我尝试在标准代码中应用大部分重构。由于测试不同场景所需的细微变化,它通常在测试中效果不佳,但在部分内部可能存在共性,并且在可能的情况下我会进行整合。随着项目的发展,这确实减轻了后期所需的更改;就像在您的标准代码中一样,更改一个位置而不是 20 个位置更容易。

      【讨论】:

        【解决方案3】:

        我更愿意将单元测试视为纯函数式程序,以避免必须对其进行测试。如果一个操作在测试之间足够常见,那么我会针对标准代码库对其进行评估,但即便如此我也会避免重构测试,因为我倾向于有很多测试,特别是对于 gui 驱动的 BL。

        【讨论】:

          【解决方案4】:

          我使用 selenium 进行功能测试 我正在使用 JUnit 来测试我的控制器。

          我将模拟控制器使用的服务或资源并测试以查看控制器重定向到的 URI 等...

          此时我唯一没有真正测试的是视图。但我采用了功能测试来弥补。

          【讨论】:

            猜你喜欢
            • 2021-09-09
            • 2017-12-23
            • 2011-08-16
            • 1970-01-01
            • 2021-01-07
            • 2016-08-31
            • 1970-01-01
            相关资源
            最近更新 更多