-
-
Save justinko/1273411 to your computer and use it in GitHub Desktop.
# 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 |
@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.
@dchelimsky I was talking about being able to do this:
Currently it doesn't work because I need to call
visit
inbefore(:each)
which will trigger 3 requests per eachit
block. This is a performance killer and in case of a request spec I don't see any value in being forced to usebefore(: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?