我知道大多数RoR程序员都在测试成瘾者，并且我了解大型测试套件的优势，但是当我开始测试时，我从来没有得到如此大型的套件，而且我总是想知道“我是否以正确的方式进行测试？真的有效率吗？”。我经常处理集成测试，仅测试应用程序的行为方式。
首先，测试真的值得吗？我的意思是，花在编写测试上的时间真的值得吗？
然后，我使用RSpec，我最近发现了Cucumber，使用了一段时间，但我不知道编写所有这些步骤是否真的值得一试？我知道我可以重用步骤，但是我不知道这些步骤是否太完整：例如，我一直在使用a，Given I am logged in as (.+)但是我不知道是否必须在其定义中说，Given there's a user called $1因为如果创建了它就可以复制用户但这并不值得总是先走一步Given I am logged in as (.+)。很多代码可能很少有用。我猜每天测试的零件上都没有新的错误……与RSpec相比，Cucumber真的值得吗？
Answers:
我的“啊哈！” 当我真正坐下来阅读有关该主题的权威资源，Rspec和Cucumber书籍时，就发生了在Ruby和Rails中进行测试的时刻。我分享了您最初对Cucumber的不屑一顾，但是后来我意识到我是从错误的角度看图片的。
基本上，Cucumber是关于BDD（行为驱动的开发）的-您将使用Cucumber来计划功能，接下来将要进行的工作。嗯，接下来，您希望用户能够在论坛上发布帖子或其他内容（以举个例子为例）。因此，您可以编写简单的内容。
Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.
请注意，其中几乎没有任何相关代码的引用。这就是您的步骤。重构代码时，可能必须更改步骤定义，但是行为（您的功能）将永远不需要更改。
现在，每次您运行Cucumber功能时，您几乎都将被引导到如何使用TDD（测试驱动的开发）来测试功能。这是使用RSpec在较低级别完成的。
第一次运行-我的第一步定义未定义。复制该块以在user_steps.rb甚至session_steps.rb中定义它，因为它与用户及其会话有关。现在，您如何定义用户已登录？您可以引导他们完成登录过程。
Given /^I am logged in$/ do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_button 'submit'
end
应该都开心。第二步。
Given /^I can see the post "(.+)"$/ do |name|
visit post_path(Post.find_by_name(name))
end
再次很容易。请注意，如果我们完全重做登录过程，或者帖子的定义和显示方式，则不必更改行为。第三步。
When /^I vote the post up$/ do
pending
end
在这里，您开始谈论新功能，但是您还不太了解它的工作方式。您如何对帖子进行投票？您可能会点击+1或类似图片，然后在控制器上进行ajax发布，并返回JSON等。因此，现在您可以进入纯Rspec测试。
所有这些都不会影响行为-但是，当您完成了较低级别的测试后，对于如何对帖子进行投票就很难填写步骤定义了。它可能很简单click_link '+1'。其余步骤是测试结果，同样应该直接进行。完成后，您便知道功能已完成并完成。如果必要的行为发生了变化，则可以调整功能，否则可以完全安全地调整实现代码。
我希望这是有道理的。这一切都让我无所适从，但我认为它证明了BDD和TDD之间的区别，以及为什么Cucumber和RSpec可以满足不同的需求。
我认为测试是一门艺术。最初（使用RSpec或任何其他框架）进行TDD感觉就像是在“浪费时间”。这是可以理解的，因为您没有编写任何生产代码。
但是，当您需要增强代码库并确保其他所有功能仍然有效时，就会开始看到TDD的好处。 TDD可帮助您尽早发现回归错误。这样做节省了我很多时间，因为我进行了重点测试，指出了我的错误。
此外，进行测试对于代码审查可能是有益的，因为您的审查者可以看到您正在测试的方案以及如何使用您的代码。
一旦您陷入TDD的热潮，做任何其他事情都会感觉不对。
我的看法是，您对黄瓜很感兴趣。编写所有这些步骤是很麻烦的，其好处并不能证明其痛苦。我在这里广泛地介绍了使用黄瓜的六个缺点：为什么要打扰黄瓜测试？
使用Rspec或Test :: Unit进行的单元测试和常规集成测试确实很有意义，但是幸运的是，这些方法的编写速度比Cucumber测试快得多。首先，您可以使用纯Ruby，而不必使用Gherkin冗长而笨拙的语法。
我个人认为是那样RSpec testing is a definite must。例如，假设您要编写一个新功能，并且该功能还引用了其他功能，并且该功能可能会被其他模块或方法引用。那么，如何确保所编写的内容不会破坏应用程序的任何其他部分呢？
假设您有一个大型应用程序，并且您编写的代码比整个应用程序小，您是否会通过单击应用程序中的每个链接以确保每次更改一行代码都可以正常工作来重新测试整个应用程序？
但是，我认为黄瓜测试不是必须的。我认为使用RSpec本身的集成测试更有意义，除非您必须让客户检查测试。根据我的经验，哪一个是RARE。如果您的团队完全由开发人员组成，那么我认为您应该代替Cucumber步骤进行RSpec功能测试。而且我认为在RSpec 3 DSL之后，测试几乎是可读的。
例如：
黄瓜步骤定义：
Given /^I am logged in$/ do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_button 'submit'
end
RSpec功能测试：
feature 'Given the user is logged in' do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_link_or_button 'submit'
end
我认为RSpec功能不是具有Cucumber功能，而是可以做相同的事情，而无需编写其他步骤定义。
除此之外，这也纯粹是您自己的偏好。
希望这可以帮助您了解一点。
我认为首先要区分实践和具体框架。黄瓜不是BDD，RSpec是非TDD。
如果要测试系统RSpec是一个很好的工具，则可以使用RSpec进行TDD或BDD，实际上TDD和BDD是同一回事。有人说“ BDD TDD做得正确”，我完全同意这一点，BDD主要是关于测试功能/行为，而不是测试方法/类。实际上，肯特·贝克（Kent Beck）描述了其TDD的功能，但是BDD帮助很多人理解了这一关键差异以及Dan North对开发社区的巨大贡献。
如果您认为需要一个更好的工具与业务人员进行交流，请使用Cucumber，例如，如果黄瓜允许您的业务人员或产品负责人帮助团队编写或修改方案，请使用Cucumber。其他人喜欢黄瓜，因为这种情况对于系统来说是非常好的实时文档，如果您认为需要这种文档，请尝试黄瓜。
综上所述：
当然，最后两个成本较高，您需要评估是否确实需要并且值得付出努力，这当然取决于您的项目和环境以及您的决定。
但是请始终记住，RSpec和Cucumber只是工具，工具可以解决具体问题，您想解决什么问题？，问问自己这个问题，您可能更适合选择正确的工具。成为一名更好的程序员，而不是使用X或Y框架/工具/库/技术来做出决策。