Ruby on Rails

As a quick summary, Capybara is an acceptance test framework and as such, tests should be written from a browser or user's perspective. With the rspec-rails gem, tests found in spec/requests directory have access to methods that expose lower-level details like requests and responses(methods like get, put, post.) So if Capybara tests are also found in that same spec/requests directory, you are able to use both the Capybara DSL and the free methods that are meant for integration tests which causes a conflict and leads to some developers using a mix of both. This leads to ugly test suites. 

The solution they came up with is to create a separate directory meant for use with Capybara DSL, which is spec/features and another directory (spec/api) meant for use with the Rails provided integration test tools. 

Michael Hartl will be releasing a newer version of his tutorial sometime in the future which will provide more up-to-date material. You might also want to look at RSpec's 'expect' syntax for its assertions. They plan on deprecating the 'should' syntax possibly as early as RSpec 3.0.

On Sunday, March 31, 2013 1:57:30 PM UTC+8, Peter wrote:

Hello Everyone,

I am new to Ruby on Rails. I just finished Michael Hartl's Ruby on Rails Tutorial and I just started on Agile Web Development with Rails, Fourth Edition by Sam Ruby. In trying to build confidence and proficiency, I started building small apps and decided, as I had learned from Michael Hartl, to use capybara and rspec. But when I tried it nothing was working. It turns out, this was the reason:

If you are using Rails, put your Capybara specs in spec/features.

 

And in order to use the tests I had created in spec/requests, I have to do this:

If you are not using Rails, tag all the example groups in which you want to use Capybara with :type => :feature.

Can anyone explain the reasoning behind this? I'm sure there is a good reason for this that my newbie self does not comprehend yet. Thank you in advance.

p