【问题标题】:Does cucumber do away with the need to write unit tests?cucumber 是否不需要编写单元测试?
【发布时间】:2009-09-19 15:56:41
【问题描述】:

我对 Ruby/ROR 可用的测试框架数量之多感到有些困惑。

我最近看了Cucumber Railscasts,发现它们很有趣。所以我开始玩一出戏,然后在概念上很难看出我应该在哪里进行各种测试。

似乎很有可能在 Cucumber 中完成所有可以在单元测试中完成的事情,所以我需要编写单元测试还是应该只编写我的功能定义并专注于提供尽可能好的覆盖率使用它。

我应该使用 Rspec 还是 Test:Unit 创建单元测试?当我测试 Ajax 功能时,我应该使用 Selenium 还是 Watir?

这里似乎有很多选择,我正在努力寻找使用哪些工具以及界限在哪里。

其他人对 Cucumber 的体验是什么,以及在编写 Cucumber 集成测试和基于 Test:Unit 和/或 Rspec 的单元和功能测试之间划清界限的地方。有没有人知道关于这个主题的一篇很好的文章,建议在测试方法和各种工具的优缺点之间划清界限。

我很欣赏其中一些是主观的,但对于如何解决此问题的常用方法将受到欢迎。

【问题讨论】:

    标签: ruby-on-rails ruby testing


    【解决方案1】:

    在高层次上使用 Cucumber 来描述用户应该能够看到和执行的操作。使用 RSpec、Test:Unit、Shouda 等编写单元测试。直接来自the horse's mouth

    当您决定要添加新功能或修复错误时,请先编写描述该功能应如何工作的新功能或场景。不要写任何代码(暂时)。

    ...

    这是您开始编写代码的时候。首先编写几行代码来解决您从 Cucumber 中遇到的故障。再次运行黄瓜。重复并冲洗,直到您对自己的功能感到满意。当您深入了解细节时,下拉一个抽象级别并使用 RSpec 或任何 Ruby 测试框架为您的类编写一些规范/测试。

    Cucumber 用于测试您的整个堆栈,而不是“单元”。

    您需要决定在哪里划清界限,但是黄瓜测试中可能不会涵盖很多幕后内容。假设在注册时,我填写了一个表格,包括我的姓名、电子邮件、电话号码等。单元测试可能会检查新的User 是否也会创建一个新的TelephoneNumber。从用户的角度来看,他们并不真正关心它创建了一个新的TelephoneNumber,他们关心的是一旦他们注册了,他们就有了一个帐户并且可以看到他们的电话号码。

    我没有太多太多编写黄瓜测试的经验(还没有),但我希望这会有所帮助。

    【讨论】:

      【解决方案2】:

      当一个单元测试失败时(我的意思是一个真正的单元测试,它使用模拟来单独测试一个方法),它会告诉你哪个“单元”有问题。当验收测试失败时,它会告诉您哪个“功能”有问题,而不是问题出在哪里。

      【讨论】:

        【解决方案3】:

        当您创建一个 Rails 应用程序时,默认情况下您会获得功能、交互和单元测试。 Cucumber 是一项附加测试,它也是一种测试用户体验的方法。当他们单击标有“go”的按钮时,他们应该看到呈现的是“success”而不是 404。这将确保您所做的任何事情都不会意外地破坏用户体验,并且从上到下您的应用程序适用于最常见的情况你能想到的用例。其他测试旨在确保没有任何问题,并且您已经使用显微镜检查过模型和方法。可以用 cucumber 完全复制单元测试,但这会很痛苦(而且执行起来非常慢,尤其是在使用 selenium 的情况下)。编写测试的最佳时间是在您开发代码时,最快速和最简单的方法是使用内置的 rails 测试,也许还有一些额外的帮助,例如 shoulda、rspec,我也是工厂女孩的超级粉丝。如果您还没有查看过 www.railscasts.com 对黄瓜、rspec 和 factory-girl 的精彩介绍,...我知道这个问题已经得到解答(不是),但这是我的两分钱.祝你编码好运!

        【讨论】:

          【解决方案4】:

          我已经为这个问题思考/挣扎了很多,这就是我到达的地方。

          黄瓜在前,黄瓜在后。 Cucumber 将提供主要的测试覆盖率。

          执行应用程序实际业务工作的核心模型方法也应该通过 rspec/单元测试来开发/覆盖。

          为什么还要进行单元测试?

          1) 单元测试将测试运行得更快。 2)这个核心业务逻辑可能(可能)以多种方式使用,超出当前视图(Cucumber 测试通过)。这些方法应该用所有类型的可能的输入和输出直接调用测试中的方法。

          为什么不对其余的模型、控制器和视图进行单元测试?

          1) Cucumber 已经覆盖了一次。 2)我发现views-controller-some-model-methods都一起工作来完成事情(想想一切都为了登录而练习);所以我喜欢一起测试它们。

          【讨论】:

          • “黄瓜第一,黄瓜最后”很好的引用。我认为这个答案更符合像我这样的初学者所需要的水平。
          【解决方案5】:

          过去半年左右我一直在练习 Cucumber/RSpec 做 BDD。

          首先BDD不好入门,刚开始会觉得不自然。

          但是一旦你进入它,就没有其他方法可以进行编程了。

          回答你的问题。要测试 Javascript,您需要一个可供 Cucumber 使用的 Capybara 使用的 javascript 驱动程序。

          capybara-webkit 是现在所有酷孩子都在使用的东西

          有一件重要的事情需要注意。

          集成测试很慢。

          单元测试很快,但也可能很慢,因此使用正确的数据库清理器并编写具有良好隔离性的良好测试非常重要。

          我非常满意的测试设置:

          装货叉的防护装置 Spork 用于更快的测试 用于集成测试的 Cucumber 用于 javascript 测试的 capybara-webkit 用于单元测试的 RSpec

          我不做视图测试和控制器测试,因为我认为这些是多余的,因为对 XPATH 的良好了解会让您编写出色的测试,甚至涵盖您的页面布局和结构。

          【讨论】:

            【解决方案6】:

            我个人认为你不应该停止编写单元测试。作为一种验收测试工具,Cucumber 应该取代您的功能测试,如果您编写,则应该查看测试。

            Cucumber 特性应该是简单的,并且与给定特性所具有的真实用户价值相耦合。

            【讨论】:

              【解决方案7】:

              根据我的经验,Cucumber 和 Rspec 具有不同的吸引力。从开发人员的角度来看,Rspec 对我很有吸引力,因为它易于编写并且在出现问题时提供非常快速的反馈。作为开发人员,Cucumber 对我没有吸引力,因为它的运行速度不如 Rspec。但是,作为业务利益相关者,Cucumber 确实吸引了我,因为它提供了对所有功能的全面覆盖。

              帮自己一个忙,继续编写单元测试。

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 1970-01-01
                • 2010-11-28
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2012-08-25
                • 1970-01-01
                • 2017-09-30
                相关资源
                最近更新 更多