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

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
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

This topic is locked and can not be replied to.