RSpec vs Cucumber (RSpec stories)

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

My take is that it's a bad idea to use Cucumber in most situations due to the costs in productivity its syntax incurs on you. I wrote extensively on the topic in Why Bother With Cucumber Tests?

Solution 4

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.

Solution 5

Nowadays you can use rspec with Capybara and Selenium Webdriver and avoid having to build and maintain all of the Cucumber story parsers. Here is what I would recommend:

1. Write out your story
2. Using RSpec, I would create an integration test ex: spec/integrations/socks_rspec.rb
3. Then I would create an integration test which includes a new describe and it block for each scenario
4. Then I would implement the minimal functionality require to get the integration test and while going deeper back (into controllers and models, etc) I would TDD on controllers and models.
5. As you come back up your integration test should pass and you can continue to add steps to the integration test
6. repeat

One thing to note, however, is that the controller and integration tests have overlap that may not be necessary so you have to use your best judgement so you do not waste your time.

Also, once you find your groove you will find it most enjoyable to develop using BDD, until then don't feel guilty if you don't feel like you are doing it perfect and don't over think it. You will do great!

View more solutions

Comments

[Ariejan]

Exactly. Cucumber describes usage of your application. E.g. "I click here and I expect to get this or that result". Specs are more on 'model' level. Like, when I call that methods with such-and-such parameters, I expect it to return this result.

[Andy Waite]

I wouldn't say that Cucumber was essential, but you certainly should have some kind of integration tests, since unit tests are normally used only for testing classes in isolation.

[Marnen Laibow-Koser]

Right. And in most cases, Cucumber is the nicest way of writing integration tests.

[huug]

I have read your article and as a fan of cucumber, I must say that I agree with many points you cite in your article. Although, I still think cucumber is a good way in formalizing tests and making them easily legible to outsiders.

[Graham Ashton]

Jack - fantastic post. Thanks so much for writing it, you've saved me the trouble of doing it myself.

[Graham Ashton]

huug - It might be a good way of exposing tests to "outsiders", but you show me a non-technical team member who wants to read the tests, and I'll show you a team that's wasting its budget. Also, I'm yet to work with a non-technical member of a project who would want to waste their time reading tests. I dunno, maybe I'm lucky...

[Graham Ashton]

You're conflating two separate issues; 1) is it good to do integration and acceptance testing, and 2) is cucumber a good tool to write those tests in. For 1 - yes, it's clearly a good idea. For 2, rarely is it more efficient for a development team to write tests in a language with so much indirection, when you can write very legible integration and acceptance tests in rspec and capybara (or - heaven forbid we might investigate Ruby's standard library - test/unit or minitest, along with capybara). See the post that Jack Kinsella links to below.

[rdamborsky]

There is a very nice example of the cycle Outside-in BDD.

[dpapadopoulos]

Totally agree with you Abie! Cucumber integration is vital!

[Marnen Laibow-Koser]

Downvoted. I find that describing user features in user terms is useful to me, as a developer, regardless of whether users ever read my Cucumber stories. That’s why I use Cucumber on all my projects and encourage others to do likewise.