Question

I’m getting a little bit confused about how to organize my integration tests. Right now, they are organized according to page structure:

post_pages_spec.rb:

require 'spec_helper'

describe "Post pages" do

  describe "show page" do

    describe "post destruction" do

    end

    describe "edit" do

    end

  end

  describe "post creation" do

  end


end

As you can see, delete and edit are inside the show action, because they appear in the show page.

This is another way of organizing them (based on the REST actions):

post_pages_spec.rb:

require 'spec_helper'

describe "Post pages" do

  describe "show page" do

  end

  describe "post destruction" do

  end

  describe "post creation" do

  end

  describe "edit" do

  end
end

Which structure is clearer and easier to maintain?

Answer 1

Assuming you really are asking about integration tests and not controller tests, I like to organize integration tests from the users perspective, and by the type of user. Ex. one file for registered users, one file for admins, one for not registered users, etc and as necessary.

The justification for this is that I have found, as a general heuristic, that the same user types have the same prerequisites for a feature, and thus fit well together. For example, a registered user viewing a post might have a lot of scenarios focusing on CRUDing existing post content, where a non-registered user might have scenarios focusing on post recommendations. Since is likely that these different perspectives would have different setups and teardowns, it is also likely that they will be easier (ie. DRY-er etc) to maintain separately.

Also, it reads nice 🙂 Ex:

describe "Registered User" do
  context 'creating a Post' do
    it "succeeds given all fields are filled out"
    it "displays errors to the author if a field is missing"
  end
end