你测试你的控制器多少？答案

【问题标题】：How much do you test your controllers?你测试你的控制器多少？
【发布时间】：2009-09-12 09:13:53
【问题描述】：

我目前从 BDD 开始 - 我之前没有写过任何测试。我总是尽量让我的模型胖而我的控制器瘦。

您认为需要控制器规格吗？

最好的问候

【问题讨论】：

标签： ruby-on-rails rspec bdd

【解决方案1】：

是的。测试是否进行了正确的调用，并在必要时进行了正确的重定向，并测试了是否呈现了正确的页面。因此，请测试您的应用程序是否按预期运行。

【讨论】：

我已经通过 Cucumber 测试了视觉行为的许多部分。

【解决方案2】：

就我自己而言，我试图了解在测试中寻求高水平的代码覆盖率与维护一组可能相当脆弱的测试的长期成本之间的平衡。

假设我们有一个控制器

    try {
        result = mode.doSomething();

        if  (result.count == 0 )
             message = "none found"
             redisplay criterion page
        else if (result.count == 1 ) 
             display detail page
        else 
             display list page
    } catch exception {
        message = "bad things happened, please try again"
        redisplay criterion page
    }

一个初步的想法是，三个计数案例（0、1、许多）的测试可能比例外案例的测试价值更低，并且更容易发生变化。价值较低，因为 a)。其他测试将在页面显示中发现问题 b)。测试非常接近于简单地重现代码。

    code: go to page X
    test: did you go to page X?

如果开发人员选择了错误的 X，他的测试也会出错！如果 UI 的可用性测试表明 Y 是更适合显示的页面，那么我们会同时更新代码和测试。测试真的有什么成果吗？

而异常情况在正常的 UI 测试中可能很难练习，而使用模拟测试则非常容易。而且，我们确实需要正确处理异常之后的行为。

【讨论】：

我假设您首先编写了重定向到 X 的测试。当您更改操作重定向的位置时，您首先更改测试，然后使其通过。验证这一点比登录应用程序并查看它是否有效要快得多。即使使用 cucumber，规范/测试仍然比设置和抓取功能更快。我坚信“如果你写一行代码，先写一个失败的单元测试”。但是，如果您想避免这些，请使用类似inherited_resources 的抽象并停止编写该代码和测试。
我非常同意你的观点，但是暂时扮演魔鬼的拥护者。有时我们需要运行该应用程序来测试美学、可用性等。重定向中的缺陷会在那时被发现。我们在重复努力吗？我们是否发现了足够的缺陷来保证我们的努力？假设我们违反（甚至通过正式记录的政策）在编写三行代码之前没有为三行代码编写测试，影响会有多大？
手动测试可能会发现缺陷，但为什么要让测试人员看到你可以用 rspec + cucumber 轻松捕获的东西呢？您可以轻松地自动化许多不同的测试用例，并且可以在最终用户确实发现缺陷时添加新的测试用例。请记住，这些测试不仅适用于您构建应用程序，还可以帮助您以后维护它，尤其是当您想要进行框架更新时。
魔鬼的拥护者说：因为无论如何测试人员都会“轻松”而不是什么都不做。测试当然与初始开发一样多用于维护，因此有维护成本，随着 UI 的变化，案例流失，许多（每个？）“失败”由测试用例修复，我们实际上从未捕获任何真正的错误。新版本的 Struts 或任何不会破坏“如果结果 == 2 转到页面 a”的代码，我们正在对结果是进行单元测试b> 2.

【解决方案3】：

您认为需要控制器规格吗？

如果您将它们与良好的集成测试结合起来，我认为它们是不必要的。我发现应用程序的可用性非常重要，因此对于控制器/视图的每次更改，我都会单击应用程序并了解它的感觉。在我看来，为控制器和视图创建“愚蠢”测试并没有太多额外价值。

对于集成测试，我使用的是 Cucumber。这使得测试整个堆栈并确保您的应用程序以您想要的方式执行成为可能。对于业务逻辑（胖模型），我仍然使用 RSpec。

【讨论】：