gistfile1.rb

# In request/integration/acceptance specs, the more examples you have, the slower the spec.
# This obviously applies to any other kind of spec, but the performance trade off
# is not worth it for high level tests - it can potentially cost you seconds.

# Hard to read/process but fast
describe 'viewing a user profile' do
  before { login }
  
  it 'displays the name, birthdate, active, address, phone number, last login'
end

# Descriptive but much, much slower
describe 'viewing a user profile' do
  before { login }
  
  it 'displays the name'
  it 'displays the birthdate'
  it 'displays the active status'
  it 'displays the address'
  it 'displays the phone number'
  it 'displays the last login'
end

# (this is the proposal)
# Balanced - descriptive and fast (this would also reflect doc formatting)
# Downside: each description is not directly tied to an expectation
describe 'viewing a user profile' do
  before { login }
  
  it 'displays the name',
     'displays the birthdate',
     'displays the active status',
     'displays the address',
     'displays the phone number',
     'displays the last login'
  end
end

# Highest level (too high level IMO)
describe 'viewing a user profile' do
  before { login }
  
  it "displays the user's info"
end

@solnic - every time somebody puts the When (in Given/When/Then) in a before hook, a kitten dies. I appreciate the desire to do a When once and expect different Thens, but I think before hooks are the wrong solution. I think that jasmine handles this nicely by supporting multiple failing Whens per-example, and it's something I've thought of adding to rspec. I don't think, however, that this solves the issue @justinko is raising here.

That will be displayed as one line when the spec is run with the doc formatter option.

@justinko - that's not what I see.

describe "user profile" do 
  it %q|displays
    name
    birthdate
    active status| do
  end 
end 

Output:

user profile
  displays
    name
    birthdate
    active status

@justinko - actually I think multiple failures per example would solve the issue, combined with the example in my last comment. WDYT?

@dchelimsky I was talking about being able to do this:

describe 'home page' do
  before(:all) { visit home_page_path }

  it 'has menu'
  it' has header'
  it 'has footer'
end

Currently it doesn't work because I need to call visit in before(:each) which will trigger 3 requests per each it block. This is a performance killer and in case of a request spec I don't see any value in being forced to use before(:each). I do understand why it's a great practice in unit specs but we're talking about higher-level full-stack acceptance specs here.

So yeah, I put my 'When' in a before hook and I'm surprised that I'm killing kittens by doing so. Where should I put visit call if not in a before block?

@dchelimsky - Shit, okay I was wrong about it being on one line. However, in order for it to be nested correctly (as in your example), you need to have the correct amount of white space. So basically you'd have to keep that hard-to-read it block, which doesn't reflect the formatting output :(

@dchelimsky - Okay, this is kind of crazy...

describe 'the user profile' do
  before { expensive_operation }

  group 'displays the user info' do
    specify 'name'
    specify 'birthdate'
  end
end

group holds the examples, and runs them in its context (which has the before block). Its description is also used.

@solnik - right now it's your best option. It's rspec's lack of a better option that is forcing the kitten-killing, which is why I think either multiple-failed-expectations-per-example would be a better solution. If you care about documenting the outcomes, but don't mind multiple expectations per example, then formatting the docstring as in my example above would work as well.

@justinko - the HERE doc formatting problem solvable. Ideally, we'd be able to do something like:

describe "user profile" do 
  it %A{displays
          birthdate
          active status} do
    user = User.new(
      :birthdate => Date.new(1963, 11, 26),
      :active => true
    )
    login_as user
    visit my_profile_path
    page.should contain("Active")
    page.should contain("Nov 26, 1963")
  end 
end 

... where A means HERE doc aligned to the first column after the delimiter. But in absence of such in Ruby, I wonder if we could just handle that in rspec without tripling the time it takes to present the doc format?

re: the group idea, one thing I definitely don't want to do is add more DSL that abstracts things further than they are already.

@dchelimsky - Comma separated example descriptions would give us complete control of formatting. And plays more nice with editors. Metadata would have to be symbols.

However, do you have this problem that I'm talking about? I would only want to add something to RSpec if others are experiencing this pain.

@justinko - I've seen a lot of complaints about this issue, though generally related to AR fixtures and/or factory-created models (i.e. create the model instance in before(:all) and have it not roll back until after(:all)). So I believe the pain is widely experienced.

The comma separated descriptions is interesting, but adding it could do odd things to existing suites as multiple args are currently concatenated so you can do things like describe Foo, "#bar" do. That's legacy, and I'd have no problem breaking that in a 3.0 release, but no sooner.

@dchelimsky - Yeah, the comma separated strings don't really solve anything or offer much to be honest. They need to be tied to an individual expectation or it's just not worth it.