RSpec vs Cucumber (RSpec stories)

snitko_34134 0
Viewed 30629

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.

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?

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?

rspec-stories cucumber rspec integration-testing unit-testing
6 Answers

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.

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.

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.

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.

user_531660

Think of it as a cycle:

Write your Cucumber feature, then while developing the pieces for that feature, write specs to complete the individual components. Continue completing specs until you've written enough functionality for the feature to pass, then write your next feature.

user_2839520

A Cucumber story is more a description of the overall problem your application is solving, rather than if individual bits of code work (i.e. unit tests).

As Abie describes, it's almost a list of requirements that the application should meet, and is very helpful for communication with your client, as well as being directly testable.

user_1317010

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?

You still need Cucumber. You need it to document how you see the system working, and you need it to make sure you haven't broken functionality when you change things.

In other words, you need Cucumber stories for the same reasons as you need unit tests -- they just work on a higher level of abstraction.

user_1090110
Related