Forum: Ruby on Rails Best practices for capybara's features spec?

F8069adedbe2d37460c54eac8102351b?d=identicon&s=25 guirec c. (guirec_c)
on 2013-07-19 20:19
(Received via mailing list)

I realy like to use capybara's features spec but I have some questions
about the organisation :

1. How should I group the features specs?

For the moment, I try to group by controllers. For example, I can have a
file "users_spec.rb", "artists_spec.rb", etc... Maybe it's better to
by user story... What do you think?

2. What is a "very high level"?
I try to keep my features specs at a very high level. I test only the
interactions between the user and the application. I test only the
path". You can find one example of my tests here :

I do specs for controllers, mailers, models, etc. but is it good to also
check if a new record is added or if a mail is send in a feature spec?

I think it's not an implementation detail. The user want to have and
sended and a user created. If I check if a user is created, should I
if there is a new model or should I go to the index page and check if
user exist?

3. Is it possible to drop all technical details outside the scenario?
In some scenario, I can have this :

    AdminUser.create!(email: '', password: 'test1234')
    #... my scenario

This is not related to what the client want to have. It's only
implementation details. I know I can put it on a background but, if I
many scenarios, I should do one background per scenario. I think it's
very clean. I like to have a clean file and I don't want to use describe
and contexts on a feature spec. What do you think?

So, what do you think about all of this subjects. Your opinion will be

Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.