Add example group for features #632
Conversation
This fixes various issues with the integration between RSpec and Capybara 2.0. - It includes Route helpers, these were previously unavailable, due to the fact that the only reason they are available in request spec is that those delegate via method_missing to an IntegrationTest instance. - It adds the `:feature` type to all features. This way people can include module into `:type => :feature` examples and they will work when their specs are places in this folder. David previously commented that he didn't want to add Capybara specific behaviour outside of `rspec/rails/capybara`. I was careful to avoid doing that. The feature example group does not explicitly include Capybara, instead, Capybara is included due to Capybara itself hooking into `:type => :feature`. This is much cleaner than the way it was before. I tested this against both a freshly generated Rails app, as well as an existing, rather large project, both worked well.
|
+1 |
|
Saw that Travis failed for earlier Rails versions, so I pushed a fix. |
|
I initially thought a If capybara is not present, Unless there are strong objections, I will revert my earlier work in 96e1c33 and go with @jnicklas's. |
|
@alindeman I have no objection. @jnicklas thanks for the pull request - really appreciate the collaborative effort here. Cheers! |
|
One additional consideration (which can be addressed in a separate pull/commit) is that |
|
It seems to me like there is no harm if someone wants to use the FeatureExampleGroup without Capybara. Especially since rspec-rails tries to load capybara, so if it is available, it will be loaded anyway. Someone could use selenium-webdriver directly, for example. I don't see why that should cause a failure. |
|
My concern is confusion caused by creating a file in spec/features without Capybara installed or loaded and not understanding why there is no get/post/put/delete/head or visit. |
|
@dchelimsky: would this be an acceptable solution: jnicklas/rspec-rails@jnicklas:feature-example-group...jnicklas:with-fake-capybara Most people are going to call If you approve, I can send a pull request for that too, but let's get this one merged, so that we can move forward! |
|
@jnicklas works for me. @alindeman, wdyt? |
|
I like it. I'm pull that in, as well as fixing my quasi-conflicting changes, now. Thanks so much @jnicklas and other Capybara folks for working this, and I apologize about the delay. |
|
@jnicklas, would you mind performing similar tests against the code I just pushed to https://github.com/alindeman/rspec-rails/tree/with-fake-capybara? I kept much of your implementation, but tweaked it a bit based on the Rails code I originally wrote it against. If it works and you feel good about it, I'll merge that. Feel free to call me out on anything you see that might be an issue. |
|
@alindeman looks good to me! Good catch on the host stuff, I didn't consider that at all. |
|
Committed with 0fda98b. I will spend some time writing up more docs on this soon, but hopefully that helps remove road blocks. If not, ping me! |
|
I just pushed some new docs for feature specs. Reviews welcomed: 6e68bdd |
This fixes various issues with the integration between RSpec and Capybara 2.0.
:featuretype to all features. This way people can include module into:type => :featureexamples and they will work when their specs are places in this folder.David previously commented that he didn't want to add Capybara specific behaviour outside of
rspec/rails/capybara. I was careful to avoid doing that. The feature example group does not explicitly include Capybara, instead, Capybara is included due to Capybara itself hooking into:type => :feature. This is much cleaner than the way it was before.I tested this against both a freshly generated Rails app, as well as an existing, rather large project, both worked well.