当前位置：文江博客话题详情

TDD/BDD Rails Cucumber / RSpec 复制

发布于 2024-08-10 07:50:39 字数 393 浏览 4 评论 0原文

有人可以使用简单的用户故事来澄清 Cucumber 的用途以及 RSpec 的用途吗？前几天我购买了 RSpec 书并一直在阅读它。作者有时似乎很含糊。

我在想如果用户故事是这样的（请原谅语法不正确，这只是为了让你明白这一点）：

当用户输入无效的电话号码时然后他们收到一条消息说“无效的电话号码”

如果我写出 Cucumber 的所有代码来检查这一点，然后编写 rspec 内容，我基本上是在重复我的测试。是否有一个场景可以解释 Cucumber 测试与 rspec 测试有何不同？

我觉得你会一直在两个级别上重复测试。

如果对此没有明确的答案，我会开始认为 Cucumber 人只是不想踩到 RSpec 人的脚趾。

请帮忙。我感觉我的头快要爆炸了。

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

倾听心声的旋律 2024-08-17 07:50:39

查看 BDCasts.com 上的截屏视频可能会有用。他们将引导您完成为应用程序创建故事和规格的过程。这确实对我有帮助。还拥有 rspec 书，但仍然感到困惑。您甚至可能只想在 github 上查看他们的源代码。

对我来说，它是这样的：

Cucumber 来测试用户将看到的内容。（全栈测试）
Rspec 来测试其他所有内容。（模型、控制器）

回复收藏 0 原文

假扮的天使 2024-08-17 07:50:39

Cucumber 用于解释（描述）应用程序的一部分（故事），而不是单元测试或行为测试（这是 RSpec 的重点）

，因此，恕我直言，Cucumber 测试（故事）不能替代 RSpec 测试。

RSpec 测试倾向于推动模型和控制器的开发，而故事则倾向于推动视图的开发。

从您的描述来看，您似乎正在使用黄瓜来测试故事和行为。

回复收藏 0 原文

何以笙箫默 2024-08-17 07:50:39

将 Cucumber 视为从外到内测试整个应用程序，其中 RSpec 是特定模块的单元测试。首先指定您希望应用程序在 Cucumber 中具有哪些行为，然后下拉至 RSpec 并描述使该行为起作用的类和模块。

我花了一段时间才明白它，但我发现 Cucumber 非常适合从广义上描述您希望应用程序执行哪些功能，而 RSpec 非常擅长描述它实际上应该如何执行。

因此，您可以在黄瓜故事中说出您想要什么样的功能，并编写超级简单的步骤来提供输入并查看输出。然后你下拉到 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 并说出我希望该功能如何实际工作。

有时您的测试中会出现重复，这不是很干燥，但如果您将其视为一个详细程度的问题，那么它可能不会那么困扰您。一开始我做了很多重复的工作，直到我意识到我应该概括地说我在 Cucumber 中想要什么，然后具体地说我在 RSpec 中想要什么。

这只是一个新手关于如何使用这些工具的想法，但到目前为止它似乎对我来说效果很好。我可能给了你一个可怕的例子，但我只是试图从一般细节到我在使用这些工具时发现有用的具体细节来阐述要点。

Think of Cucumber as testing your whole application, from the outside in, where RSpec is unit testing of specific modules. You start out by specifying what behaviors you want your application to have in Cucumber then drop down into RSpec and describe the classes and modules that make that behavior work.

It's taken me a while to kind of get it but I'm finding Cucumber is really good for describing in broad terms what features you want your application to do and RSpec is really good at describing how it should actually do it.

So you would say in your cucumber stories what kind of feature you want and write super simple steps to provide input and look at output. Then you drop down to RSpec and write specifications on how it should actually do it.

Let's say your feature is the ability to search for user names on a website. You might write a cucumber feature and the first (and only the first) scenario like this:

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

You run Cucumber, it tells you the steps you're missing, you copy those and create the simple steps to check for this stuff but don't write any code yet.

When you're done with your step definitions you drop down into RSpec and start writing specifications on how you want this to work. (Cucumber of course should be failing)

describe "SearchController" do

  it "should respond to searches" do
    sc = SearchController.new
    sc.should respond_to(:search)
  end

end

You run RSpec and watch it fail then go off and write your code:

class SearchController

  def search
  end

end

That's it. Now run your test again. It should pass so start getting more specific and start describing how you will actually use the search feature. I didn't want to get too in depth into it I just wanted to give you the idea that you describe what you want in Cucumber then describe how it should actually work in RSpec.

Of course you can do everything in Cucumber or everything in RSpec but I've really found Cucumber helps me say in very simple ways what I want where if I try to do that in RSpec I get bogged down in the details. If I use Cucumber first to describe the basic feature I want and why then I can drop into RSpec and say how I want the feature to actually work.

There will be duplication in your tests sometimes, which isn't very DRY, but if you think of it as a level of detail issue it might not bother you as much. I was doing a lot of duplication of effort at first till I realized I should just say generally what I want in Cucumber then say specifically what I want in RSpec.

This is all just one newbie's idea of how to use the tools but it's seeming to work well for me so far. I've probably given you a horrible example but I'm just trying to get the point across of the general detail to specific detail I've found useful when using the tools.

回复收藏 0 原文