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.
> On Fri, Feb 4, 2011 at 3:27 PM, David Chelimsky <[hidden email]> wrote:
>> The rspec-devel list has not been active for some time, I didn't see this right away. Feel free to use the rspec-users list.
> Huh, I see. How about closing rspec-devel down then? (So long as the
> archive stays up, I guess ...)