RSpec+Capybara+Rails integration

Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RSpec+Capybara+Rails integration

Jo Liss
**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
https://github.com/jnicklas/capybara/blob/master/lib/capybara/rspec.rb
.

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
compatibility.

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
http://opinionated-programmer.com/
_______________________________________________
rspec-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Capybara] RSpec+Capybara+Rails integration

Jo Liss
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 ...)

--
Jo Liss
http://opinionated-programmer.com/
_______________________________________________
rspec-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Capybara] RSpec+Capybara+Rails integration

David Chelimsky-2
On Feb 4, 2011, at 9:22 AM, Jo Liss wrote:

> 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 ...)

Oh, the irony.

I don't know how. There is no interface for shutting down lists maintained at Rubyforge, and my backlog is deep (and this is not a huge priority for me).
_______________________________________________
rspec-devel mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-devel