[rspec-devel] RSpec+Capybara+Rails integration

Jo Liss joliss42 at gmail.com
Thu Feb 3 15:45:17 EST 2011

**Sent to the Capybara and RSpec-devel lists; I suggest we continue
the discussion only on the Capybara list.**

When Capybara is used with RSpec, it automatically configures itself
for examples of :type => :acceptance (including metadata awareness for
:driver and :js); see

Now rspec-rails (in rspec/rails/example.rb) automatically includes
FooExampleGroup modules (which in turn set the correct :type) for
files in certain directories; e.g. ControllerExampleGroup (with :type
=> :controller) in spec/controller, and RequestExampleGroup (with
:type => :request) in spec/requests and spec/integration -- but
there's no automatic :acceptance type.  This means that in order to
"properly" use Capybara with RSpec, you have to manually tag all your
Capybara examples :type => :acceptance.

It seems to me that the RequestExampleGroup was made for exactly the
kind of testing that is typically done with Capybara.  (It even
include's Capybara, if available.)  Is that correct?

If so, it seems there are broadly two ways to improve the situation:

1. Either on Capybara's side: Recommend using :type => :request, or
the spec/integration directory with Rails, as the "blessed" way to
write Capybara tests, and add support for :type => :request in
capybara/rspec.rb, retaining support for :acceptance for

2. Or on rspec-rails's side: Change rspec-rails to include
RequestExampleGroup for all files in the spec/acceptance directory --
but with :type => :acceptance instead of :type => :request.

It seems to me that option 2 could possibly cause breakage, whereas 1
is less likely to break people's code (as it only runs fairly
innocuous code for :request examples).  Also, for option 1 the change
happens on Capybara's side, which still has a zero-point version, so
changing things in slightly incompatible ways is not as bad.

I'd hence suggest option 1.  Any comments?

Jo Liss

More information about the rspec-devel mailing list