Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Adds cukes for feature specs (capybara integration)

  • Loading branch information...
commit 6e68bdd5085802b35a2270dde574d1f0d3512a03 1 parent 0fda98b
@alindeman alindeman authored
View
2  features/.nav
@@ -5,6 +5,8 @@
- Changelog.md
- Upgrade.md
- RailsVersions.md (Rails versions)
+- feature_specs:
@dchelimsky Owner

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

@alindeman Collaborator

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

Why not just features.

@alindeman Collaborator

Does features conflict too much with cucumber?

@dchelimsky Owner

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

@alindeman Collaborator

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?

@dchelimsky Owner

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:
View
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](http://github.com/jnicklas/capybara)
+ gem, version 2.0.0 or later. Refer to the [capybara API
+ documentation](http://rubydoc.info/github/jnicklas/capybara/master) 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](http://c2.com/cgi/wiki?CustomerTest) and
+ [acceptance tests](http://c2.com/cgi/wiki?AcceptanceTest).
+
+ 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
View
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](http://github.com/jnicklas/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:
View
1  rspec-rails.gemspec
@@ -37,4 +37,5 @@ Gem::Specification.new 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'
end

1 comment on commit 6e68bdd

@dchelimsky

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

@jnicklas

Looks really good!

@alindeman
Collaborator

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

@jnicklas

Why not just features.

@alindeman
Collaborator

Does features conflict too much with cucumber?

@dchelimsky

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

@alindeman
Collaborator

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?

@dchelimsky

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

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