RSpec Stories and Specs: When to use what?

Question

So I want to start using RSpec stories, but I am not sure where writing controller, model and view specs fit in.

For example, you have the story "Logging in" with "User provides wrong password" scenario, don't you end up testing the same stuff than controller/model specs (response.should render..., user.should be_nil, etc.)

So my question is: for those who are used to doing bdd (or story dd) with RoR, do you still write model/controller specs? If so, how is the workflow you follow ("first story, then narrow to specific specs")?

Answer 1

If you are starting with stories now (as opposed to having a lot of legacy stories) you may want to look at Cucumber which is the long term replacement for the RSpec story runner.

The easiest way of splitting between specs and stories is to use stories for full-stack testing of business requirements and specs for isolated low-level specifications of the components (views, helpers, controllers and models). 'Full stack' can a range from controller/model/database through client simulation with Webrat to in-browser testing with Watir or Selenium.

The ultimate 'outside in' BDD way of doing things is to start with stories based on customer requirements and then add in specs for the components you find you need when implementing the stories. Ideally you will fully cover the individual components with specs and have stories for the most important workflows of your users so you can check at the highest level that your app is delivering the functionality you have been asked for.

Answer 2

I find stories are useful when they test the behaviour the user actually performs or observes - so rather than testing that the "failed login" template is rendered, test that the response contains "failed to log in". IMHO it's better if stories never refer to models, views or controllers directly, although sometimes it's hard to get the steps working without creating model instances manually.

As I see it, view, controller and model specs are only part of the picture. They speak the language of implementation ("controller action X should do Y to model Z"), and test that the individual parts of your app each do the right thing. Stories complete the picture by speaking the language of the user ("when I post a comment I should see the comment I posted") and testing that the parts fit together in a way that meets the customer's acceptance criteria.

I find a useful workflow is:

• write a story scenario describing the functionality I need to add.
• as soon as possible, write steps for that story, so that you can run it (even if all the steps fail).
• write a spec for something needed by that story (model may be a good place to start).
• write code to make that spec pass.
• write more specs and code until the story passes.

That way the story can guide you in what your specs need to test.

Edit: this is a good article which touches on the relationship between stories and specs.

Answer 3

Pat Maddox (RSpec core team) thinks that under some assumptions, you can skip controller specs when using Cucumber stories/features

Read about his point of view here