我应该使用 RSpec 还是 Cucumber
我是 Rails 3 中单元/功能测试的新手。所以我现在就开始，晚做总比不做好。
我在 /lib/mailingjob.rb 中有一个名为 find_reply(body) 的方法，
现在我正在使用黄瓜来测试它，但考虑到这都是后端，没有网络界面，我不应该使用黄瓜吗？
我发现何时使用 RPSEC 与 Cucumber 令人困惑。
谢谢
I'm new to unit/func testing in Rails 3. So I'm starting now, better late than never.
I have a method in /lib/mailingjob.rb called find_reply(body)
Right now I'm using cucumber to test this but given that this is all backend, no web interface to this, should I not be using cucumber?
I'm finding when to use RPSEC vs cucumber confusing.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在我看来，你需要同时使用两者。 Rspec 非常适合单元测试，即测试模型、控制器、视图。另一方面，cucumber 是一个非常好的工具，可以检查完整的场景，例如用户登录、单击链接并且他应该查看此内容。
我强烈建议您查看 railscasts.com 上的 Cucumber Railscast。另外，请确保您使用 webrat 以及自动加载规范的工具，例如 watchr（我更喜欢）。
In my opinion, you need to use both. Rspec is very good for unit testing, that is testing models, controllers, views. On the other hand, cucumber is a very nice tool to check full scenarios like a user logs in, clicks a link and he is supposed to view this.
I highly advise that you take a look at the cucumber railscast from railscasts.com. Also, make sure that you use webrat and maybe something to auto load your specs like watchr(which i prefer).
我建议您永远不要使用 Cucumber，除非您专门受聘为业务分析师。这让您的生活变得更加轻松：您的所有测试都将在 Rspec 中进行。
黄瓜会损害你的生产力和理智。运行并行测试环境、添加抽象层以及用奇怪的语法破坏编辑器都会浪费时间。我在我的博客上对此进行了广泛的讨论：
为什么要费心进行 Cucumber 测试？
I'd advise you to never use Cucumber unless you are specifically employed as a business analyst. That makes your life much easier: all your tests will be in Rspec.
Cucumber takes a toll on your productivity, and your sanity. Running parallel test environments, adding layers of abstraction and breaking your editor with its odd syntax make for lost time. I've written about this extensively on my blog:
Why Bother With Cucumber Testing?
如果我还没有 Stack Overflow 帐户，我就会创建一个帐户来写这篇文章。我敦促你重新阅读@Jack Kinsella的回答
我大约 3 个月前进入了 BDD，爱上了它，并很快开始使用 Cucumber 来做所有事情。我把它强加到每个项目中，不管是什么。
最近，我不得不学习另一种语言，我的第一步就是设置测试环境。我遇到了这 3 篇文章：
老实说，他们的内容并不那么重要；重要的是他们暗示了一个整体的想法。我开始怀疑自己一直以来都错误地使用了 Cucumber，并开始寻找答案。今天早上我发现了你的问题，@Jack Kinsella 的博客文章
@Jack 直接出来并说这个想法我相信这些文章暂时流传。他还为我提供了我正在寻找的语言。我现在认为他的文章是关于这个主题的最终结论:)
根据他的说法，我们实际上使用 Cucumber 的目的是“集成测试”。我以前一直不明白这意味着什么
这是多么优雅的解决方案。没有第二个测试环境。没有步骤目录和大量额外文件！
我有那么一刻“但我喜欢 Cucumber 如何将英语与代码分开”。常规 bdd 也可以这样做。 "rspec --格式嵌套"或 Jasmine 测试结果
@Jack 是对的。黄瓜没有添加任何东西；不是我们一直使用的方式。而且成本很高。引用他的话：
If I didn't already have a Stack Overflow account, I would have made one JUST to write this post. I urge you to re-read @Jack Kinsella's answer
I got in to BDD about 3 months ago, fell in love with it, and quickly started using Cucumber for everything. I forced it in to every project, no matter what
Recently, I've had to learn a yet another language, and my first step was to get the testing environment set up. I came across these 3 articles:
Honestly, their content isn't that important; what's important is that they hinted at an overall idea. I began to suspect that I'd been using Cucumber wrong all along, and I went hunting for answers. This morning I found your SO question, and @Jack Kinsella's blog post
@Jack comes right out and says the idea I believe those articles were tentatively circling. He also gives me the language I was looking for. I now consider his article to be the final word on the subject :)
According to him, what we've ACTUALLY been using Cucumber for is "integration testing". I never understood what that meant before
What an elegant solution. No 2nd testing environment. No steps directory and swarm of extra files!
I had a moment of "But I love how Cucumber seperates English from the code". Regular bdd does that too. "rspec --format nested" or Jasmine test results
@Jack is right. Cucumber isn't adding anything; not the way we've been using it. And it's costing a lot. To quote him:
为了完成 SpyrosP 的答案，Sarah Mei 发表了一篇很棒的博客文章，其中描述了同时使用 Rspec 和 Cucumber 的场景。它被称为 oustide-in 行为驱动开发，你可以找到它在这里。
To complete SpyrosP's answer, there is an awesome blog post from Sarah Mei which describes a scenario where you use both Rspec and Cucumber. It is called oustide-in Behavior Driven Development and you can find it here.
不过，我认为杰克的大部分问题都可以通过一个好的黄瓜编辑器来解决。所以问题不在于黄瓜。问题是，两年前他写这篇文章时，还没有一个有能力的编辑。但如今 RubyMine 具有完整的 Cucumber 编辑功能。虽然它不是免费的，但它可以解决 Jack 的大部分问题：自动完成、指出错误、重构。所以你可能想回去检查一下他提出的观点，看看它们今天是否仍然有效。
However, I think most of Jack's problem can be solved by a good cucumber editor. So the problem is not Cucumber. The problem is that there wasn't a capable editor when he wrote this two years ago. But today RubyMine has full cucumber editing capability. While it is not free, it can solve most of Jack's problem: Auto completing, pointing out errors, refactoring. So you probably want to go back and check the points he raised, and see if they are still valid today.
我对多年后这个问题的看法非常简单：如果您现在不知道该使用什么，那就从 RSpec 开始，因为它是您始终需要的所有测试的核心。
随着时间的推移，您会发现两大测试需求：
作为一名开发人员，我倾向于认为 (1) 是针对每一个代码更改，(2) 当我完成功能和/或部署时。
拥有两个测试套件很好，因为在部署期间，您可以坐下来运行一个非常通用的测试套件：我的用户功能仍然有效吗？我最终可以部署这个吗？
事实上，它应该如此通用，以至于如果（2）中出现问题，您需要进行一些繁重的研究（表中缺少一行），而（1）中的失败应该查明存在问题的确切类。
通常，我发现自己处于这样的情况：我想要单独的集成+验收测试，而不需要 Cucumber 的负担。首先，我使用 RSpec 标签来过滤掉这些测试。每当我需要更多时，我喜欢去 Steak+Capybara 因为它在我已经非常了解的东西之上实现了类似 Cucumber 的目标。
My take so this issue many years later is very simple: If you do not know what to use now, just start with RSpec, because it is the central stone for all your testing that you will always need.
With time you will discover that two big testing needs:
As a developer I tend to think that (1) is for every single code change and (2) when I finish a feature and/or deploy.
Having two test suites is nice because during a deployment, you can sit and run a very generic test suite: Are my user features still working? Can I finally deploy this?
Indeed, it should be so generic that if something breaks in (2) you need to do some heavy research (one row missing in your tables) while a fail in (1) should pin-point the exact class with the problem.
Normally I find myself in the situation where I want separate integration+acceptance testing without the Cucumber burden. First I use RSpec tags to filter out these tests. Whenever I need more I like going for Steak+Capybara since it enables Cucumber like objectives on top of something I already know quite well.
肯定两者都用。使用 Cucumber 进行用户体验测试（视图），使用 rspec 进行内部测试（模型等）。您可以编写控制器 rspec 测试，但我认为它们不是必需的（尝试将逻辑移至模型）。
无论您的系统是什么，我强烈建议您使用 Cucumber，因为场景会让您和您的利益相关者以清晰的书面方式了解系统的功能。
您还将准备好文档，并且您将始终知道自己在哪里以及要去哪里。您将来还将把场景与支持问题联系起来。
顺便说一下，不要在场景中使用变量，它们应该是可以理解的。
如果你希望它们像 rspecs 一样快速运行，请使用 poltergeist(phantomjs)。
我一直想不使用黄瓜，因为在很多情况下它并不像 rspec 那样简单。然而，每次我明白我需要场景来完全控制项目。
Definitely use both. Use cucumber for user experience tests(views), use rspec for testing internals(models, etc.). You may write controller rspec tests but I think they are not necessary(try to move the logic to models).
Whatever your system is, I strongly advise you to use Cucumber because scenarios will let you and your stakeholders know the functions of your system in a clear written fashion.
You will also have your documentation ready and you'll always know where you are and where you are heading. You'll also relate scenarios with support issues in the future.
Cuke them right by the way don't use variables in scenarios, they should be understandable.
And if you want them to run fast as rspecs use poltergeist(phantomjs).
I've been tempted not use cucumber because in many cases it's not simple as rspec. However every time I understood that I needed scenarios to take full control on the project.