考虑将Cucumber视为从外部测试整个应用程序，而将RSpec视为对特定模块进行单元测试。您可以通过在Cucumber中指定您希望应用程序具有的行为，然后转入RSpec并描述使该行为正常工作的类和模块来开始。
我花了一段时间才真正理解这一点，但我发现Cucumber非常适合以广泛的角度描述您希望应用程序执行的功能，而RSpec非常适合描述它实际上应该如何执行此功能。
因此，在Cucumber中，您会描述您想要的功能类型，并编写超级简单的步骤以提供输入并查看输出。然后，您转到RSpec并编写有关实际执行操作方式的规范。
假设您的功能是在网站上搜索用户名。您可以编写一个Cucumber功能，第一个（仅第一个）场景可能如下所示：
Feature: Search users
In order to find people with similar interests as myself
As a user
I want to search for people
Scenario: Search for similar hobbies
Given there is a search page
And there is a list of hobbies
And one of the hobbies is "full contact ironing"
When I select "full contact ironing"
And press search
Then a list of users with the hobby "full contact ironing" are shown
你运行了Cucumber，它告诉你你缺少的步骤，你复制这些步骤并创建简单的步骤来检查这些内容，但还没有写任何代码。
当你完成步骤定义后，你会进入RSpec并开始编写关于你想要这个功能如何工作的规范。（当然，Cucumber应该失败）
describe "SearchController" do
it "should respond to searches" do
sc = SearchController.new
sc.should respond_to(:search)
end
end
当您运行 RSpec 并看到它失败后，可以开始编写代码：
class SearchController
def search
end
end
就是这样。现在再运行一次您的测试。它应该会通过，所以开始更具体地描述如何实际使用搜索功能。我不想过多深入讨论，只想给您一个想法：您可以在Cucumber中描述您想要的内容，然后在RSpec中描述它应该如何实际工作。
当然，您可以在Cucumber中完成全部测试，也可以全部使用RSpec，但我发现Cucumber帮助我用非常简单的方式表达我想要的东西，如果我尝试在RSpec中做到这一点，我会被细节缠住。如果我先使用Cucumber来描述我想要的基本功能和原因，然后再进入RSpec并描述我想要的功能实际上如何工作，效果会更好。
有时候您的测试会出现重复，这并不十分DRY，但如果您将其视为一个细节问题，它可能不会困扰您太多。起初，我做了很多重复的工作，直到意识到我应该只是在Cucumber中概括地描述我想要的内容，然后在RSpec中具体描述我想要的内容。
这只是一个新手在使用这些工具时想法，但迄今为止，它似乎运行得很好。我可能给您举了个糟糕的例子，但我只是想让您明白，从一般细节到具体细节的想法在使用这些工具时会非常有用。
