Skip to content
Browse files

Adds cukes for feature specs (capybara integration)

  • Loading branch information...
1 parent 0fda98b commit 6e68bdd5085802b35a2270dde574d1f0d3512a03 @alindeman alindeman committed Nov 11, 2012
2 features/.nav
@@ -5,6 +5,8 @@
- (Rails versions)
+- feature_specs:
RSpec member
dchelimsky added a note Nov 11, 2012

I'm not in love with the name "feature spec", though feature.feature is a bit odd as well. Any other ideas?

alindeman added a note Nov 11, 2012

True enough. I guess I just assumed that's what we'd call it since it follows spec/{models,controllers,mailers,...}.

jnicklas added a note Nov 11, 2012

Why not just features.

alindeman added a note Nov 12, 2012

Does features conflict too much with cucumber?

RSpec member
dchelimsky added a note Nov 12, 2012

If so, then we shouldn't use that word at all :)

alindeman added a note Nov 12, 2012

Uh oh :) Naming is hard, and I'm willing to defer to your better context of situations like this, @dchelimsky. What do you think we should go with?

RSpec member
dchelimsky added a note Nov 12, 2012

I think spec/features is fine for a directory, but we can describe them as "rspec features" to differentiate from "cucumber features". WDYT?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ - feature_spec.feature
- request_specs:
- request_spec.feature
- model_specs:
34 features/feature_specs/feature_spec.feature
@@ -0,0 +1,34 @@
+Feature: feature spec
+ Feature specs are high-level tests meant to exercise slices of functionality
+ through an application. They should drive the application only via its
+ external interface, usually web pages.
+ Feature specs require the [capybara](
+ gem, version 2.0.0 or later. Refer to the [capybara API
+ documentation]( for more
+ information on the methods and matchers that can be used in feature specs.
+ The `feature` and `scenario` DSL correspond to `describe` and `it`,
+ respectively. These methods are simply aliases that allow feature specs to
+ read more as [customer tests]( and
+ [acceptance tests](
+ Scenario: specify creating a Widget by driving the application with capybara
+ Given a file named "spec/features/widget_management_spec.rb" with:
+ """ruby
+ require "spec_helper"
+ feature "Widget management" do
+ scenario "User creates a new widget" do
+ visit "/widgets/new"
+ fill_in "Name", :with => "My Widget"
+ click_button "Create Widget"
+ expect(page).to have_text("Widget was successfully created.")
+ end
+ end
+ """
+ When I run `rspec spec/features/widget_management_spec.rb`
+ Then the example should pass
6 features/request_specs/request_spec.feature
@@ -19,9 +19,9 @@ Feature: request spec
Check the Rails docs for details on these methods as well.
- If you would like to use webrat or capybara with your request specs, all you
- have to do is include one of them in your Gemfile and RSpec will
- automatically load them in a request spec (a spec under "spec/requests").
+ [Capybara]( is no longer supported in
+ request specs as of Capybara 2.0.0. The recommended way to use Capybara is
+ with [feature specs](../feature_specs/feature_spec.feature).
Scenario: specify managing a Widget with Rails integration methods
Given a file named "spec/requests/widget_management_spec.rb" with:
1 rspec-rails.gemspec
@@ -37,4 +37,5 @@ do |s|
s.add_development_dependency 'aruba', '~> 0.4.11'
s.add_development_dependency 'ZenTest', '4.6.2'
s.add_development_dependency 'ammeter', '0.2.5'
+ s.add_development_dependency 'capybara', '>=2.0.0.beta4'

1 comment on commit 6e68bdd


Looks really good!

Please sign in to comment.
Something went wrong with that request. Please try again.