When should I test Views separately in Cucumber &

Question

After some time of doing Cucumber & RSpec BDD, I realized that many of my Cucumber features are just higher level view tests.

When I start writing my scenario and then go down to RSpec, I don't ever write view specs, since I could just copy and paste part of the scenario, which would be ugly dupliacation.

Take this scenario for example

Scenario: New user comes to the site
  Given I am not signed in
  When I go to the home page
  Then I should see "Sign up free"

I know that this isn't directly testing the view, but writing separate view spec to check for the same thing seems redundant to me.

Am I approaching Cucumber wrong? What exactly should I test in view specs?

Should I write them for every single view, for example testing views for actions like

def show
  @project = current_user.projects.first
end

or should I just test more complex views?

Answer 1

Don't use view specs for anything, ever. Cucumber stories -- or even RSpec integration tests -- do that better. The examples bobocopy gives are good ones for the case he postulates, but they should be rolled into Cucumber stories/integration tests, not left on their own.

Answer 2

Personally, I never use view specs when using Cucumber. To me, acceptance tests make a lot more sense, and my complex views are generally Javascript-focused and cannot be tested using view specs.

Answer 3

It's a widely-accepted (and in my opinion, incorrect) Cucumber philosophy that views should never be tested within RSpec. The argument goes that since the behavior of the view can be described in Cucumber, RSpec should stick to what it knows best -- Models and Controllers.

I argue that the "human-readable" aspect of Cucumber makes some aspects of view-speccing important. For instance, I find view specs to work very well when working in parallel with a front-end developer. If a JavaScript developer knows that he'll want to hook into a selector on your page, it's important that your view provides that selector.

For example:

describe 'gremlins/show.html.haml' do
  context 'given it is after midnight' do
    it 'has a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 00:01:00')
      rendered.should have_selector '#gremlin_warning'
    end
  end

  context 'it is before midnight' do
    it 'does not have a #gremlin_warning selector' do
      Time.stub!(:now).and_return(Time.parse '2010-12-16 23:59:00')
      rendered.should_not have_selector '#gremlin_warning'
    end
  end
end

Note that the specs do not describe the content, they are willfully brief, and they do not describe interaction behaviors. Because the view is the portion of your application that will change the most, view specs should be used sparingly.

tl;dr: View specs are for communicating a contract to other developers and should be used sparingly (but nonetheless should be used).