RSpec vs Cucumber(RSpec 故事) [英] RSpec vs Cucumber (RSpec stories)

问题描述

什么时候应该为 Rails 应用程序使用规范，什么时候应该使用 Cucumber(以前的 rspec-stories)?当然，我知道规范的工作方式和积极使用规范的方式.但是使用 Cucumber 仍然感觉很奇怪.我目前对此的看法是，当您为客户端实现应用程序并且还不了解整个系统应该如何工作时，使用 Cucumber 很方便.

When should I use specs for Rails application and when Cucumber (former rspec-stories)? I know how both work and actively use specs, of course. But it still feels weird to use Cucumber. My current view on this, is that it's convenient to use Cucumber when you're implementing application for the client and do not understand how the whole system is supposed to work yet.

但是如果我在做自己的项目呢?大多数时候，我知道系统的各个部分是如何交互的.我需要做的就是编写一堆单元测试.那么我需要 Cucumber 的可能情况有哪些?

But what if I'm doing my own project? For most of the time, I know how the parts of the system interact. All I need to do is to write a bunch of unit-tests. What are the possible situations when I would need Cucumber then?

并且，作为相应的第二个问题:如果我写 Cucumber 故事，我是否必须写规范?这不是对同一件事进行双重测试吗?

And, as a corresponding second question: do I have to write specs if I write Cucumber stories? Wouldn't it be double-testing of the same thing?

推荐答案

如果你还没有，你可能想看看 Dan North 的优秀文章，故事中有什么? 作为起点.

If you haven't already, you might want to check out Dan North's excellent article, What's in a Story? as a starting point.

Cucumber 故事有两个主要用途.首先，因为故事形式非常具体，它有助于集中产品所有者对他想要构建的功能的阐述.这是故事的对话令牌"使用，无论我们是否在代码中实现故事都是有价值的.其次，当流程运行良好，我们在开始编写功能之前拥有完整的故事(更多的是我们为之奋斗的理想，而不是日常现实)，你的验收标准就清楚了并且您确切地知道要建造什么以及建造多少.

We have two main uses for Cucumber stories. First, because the story form is very specific it helps focus the product owner's articulation of the features he wants built. This is the "token for a conversation" use of stories, and would be valuable whether or not we implemented the stories in code. Second, when the process is working well enough that we have complete stories before we begin writing the feature (more of an ideal that we strive for than a daily reality), you have your acceptance criteria spelled out clearly and you know exactly what and how much to build.

在我们的 Rails 工作中，Cucumber 故事不能替代 rspec 单元测试.两者齐头并进.在实践中，单元测试倾向于推动模型和控制器的开发，而故事倾向于推动视图的开发(我们倾向于不为我们的视图编写 rspec)并从整体上提供对应用程序的良好测试用户视角.

In our Rails work, Cucumber stories do not substitute for rspec unit tests. The two go hand in hand. In practice, the unit tests tend to drive development of the models and controllers, and the stories tend to drive development of the views (we tend not to write rspec for our views) and provide a good test of the application as a whole from the user's perspective.

如果您是单独工作，通信方面可能对您来说不是那么有趣，但您从 Cucumber 获得的集成测试可能会很有趣.如果您利用 webrat，编写 Cucumber 对您的很多人来说是快速而轻松的基本功能.

If you're working solo, the communication aspect may not be that interesting to you, but the integration testing you get from Cucumber might be. If you take advantage of webrat, writing Cucumber can be fast and painless for a lot of your basic functionality.

这篇关于RSpec vs Cucumber(RSpec 故事)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！