Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When should I test Views separately in Cucumber & RSpec workflow?

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?

like image 622
Jakub Arnold Avatar asked Dec 16 '10 16:12

Jakub Arnold


People also ask

Is cucumber good for testing?

Cucumber is an open-source software testing tool written in Ruby. Cucumber enables you to write test cases that anyone can easily understand regardless of their technical knowledge.


1 Answers

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).

like image 98
bobocopy Avatar answered Sep 29 '22 09:09

bobocopy