Ruby on Rails
Friday, July 19, 2013
Hi,
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 group 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 "happy path". You can find one example of my tests here :
https://github.com/GCorbel/lescollectionneursassocies/blob/master/spec/acceptances/artists_spec.rb
.
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 email sended and a user created. If I check if a user is created, should I test if there is a new model or should I go to the index page and check if the user exist?
3. Is it possible to drop all technical details outside the scenario?
---------------------------------------------------------------------
In some scenario, I can have this :
create_home_page
sign_in
AdminUser.create!(email: 'admin@example.com', 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 have many scenarios, I should do one background per scenario. I think it's not 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 very appreciated.
Bye!
-- 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 group 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 "happy path". You can find one example of my tests here :
https://github.com/GCorbel/lescollectionneursassocies/blob/master/spec/acceptances/artists_spec.rb
.
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 email sended and a user created. If I check if a user is created, should I test if there is a new model or should I go to the index page and check if the user exist?
3. Is it possible to drop all technical details outside the scenario?
---------------------------------------------------------------------
In some scenario, I can have this :
create_home_page
sign_in
AdminUser.create!(email: 'admin@example.com', 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 have many scenarios, I should do one background per scenario. I think it's not 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 very appreciated.
Bye!
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CABfX5PaNwkXyBfLLeKBv6X4tEAL7Ojx0exU0FdvKAzyEJKn_Cw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment