spec/acceptance directory is not marked as request #483

Closed
dnagir opened this Issue Sep 4, 2011 · 15 comments

Comments

Projects
None yet
8 participants

dnagir commented Sep 4, 2011

I have just set up Capybara with RSpec in a new Rails 3.1 app and added a simple test to spec/acceptance.

But unfortunately I get the error:

undefined method `visit' for #<RSpec::Core::ExampleGroup::Nested_1:0x0000000337f020>

If I rename spec/acceptance to spec/requests or manually add :type => :request, then it works as expected.

According to reademe:

A good place to put these specs is spec/requests, as rspec-rails will automatically tag them with :type => :request. (In fact, spec/integration and spec/acceptance will work just as well.)

So either README or the automatic tagging of acceptance directory should be fixed.

rafamvc commented Sep 22, 2011

+1

agreed, automatic tagging of acceptance would be nice, as well as ability to configure to which directory this is automatically applied to if you want something besides acceptance or requests

gorn commented Dec 4, 2011

+1

  • the same thing with integration directory for me, where evens specifying :type => :request would not help
Collaborator

joliss commented Dec 4, 2011

@gorn: Weird. Perhaps you are missing something? Check the README again, or take a look at http://opinionatedprogrammer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/ .

@ everyone else: This should be working. I have it working in a Rails 3.1 app, and grepping rspec-rails (which sets the :request type) for 'acceptance' yields:

lib/rspec/rails/example.rb
30:    :file_path => c.escaped_path(%w[spec (requests|integration|acceptance)])

If anyone wants to dig, feel free. :-)

gorn commented Dec 14, 2011

It works now. For future reference: I did fresh install following the http://opinionatedprogrammer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/ tutorial. Originally I have only followed the README.rdoc. Unfortunately I am unable to track down the step which made broke it. I think it is workt mentioning the tutorial in README.rdoc as it nicely sums up everything needed for capybara on rails as opposed to README.doc which is more general.

I agree with this issue. However if you use the acceptance testing DSL ("feature" instead of "describe"), it works fine. You don't even have to require any capybara files in the spec_helper, it seems that they are required automatically.

@joliss: I don't see "acceptance" there (line 30):
https://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/example.rb

Or am I missing something?

@joliss joliss closed this in 5462955 Dec 14, 2011

Collaborator

joliss commented Dec 14, 2011

I feel like an idiot right now. I had a local commit adding "acceptance" in my rspec-rails clone, hence my grep result -- you guys are completely right, it doesn't actually recognize "acceptance" for the directory name. I fixed the README, and my blog post as well.

I'm sorry my thinko in the README caused such trouble and confusion for you guys! I'll be more careful next time I edit. Thanks everyone for the report and the insistence. :-)

Contributor

mcmire commented Dec 16, 2011

@joliss Sorry to hijack this but I wonder if that section needs to be rewritten, again. I think that's part of the problem here. I know I rewrote it a while back, but it could be abbreviated still. This is how I imagine people reading it currently:

You can make an example group and tag it :type => :request. Oh by the way, :type => :acceptance works too. These are RSpec versions of Rails integration tests Capybara request specs blah blah. So actually scratch what I just said about :type => :request, stick your tests in spec/requests. Or spec/integration. See, easy!!

I mean I get why all that is there, because we're assuming that people aren't using Rails, and then we say "oh but if you do use Rails, then you can do this instead". Maybe it would be a good idea to move the Rails stuff down to the Rails section?

gorn commented Dec 16, 2011

My confusion was for the same reason from the other point of view - I use RoR and I somewhat did not pay attention that the README is NOT only for Rails so I did not even seeked for RoR section ;-) ... well this is called languagecetrism ;-) ... however maybe the RoR should be separated to its own section maybe even repeating some general info.

Thanks for great code BTW.

Collaborator

joliss commented Dec 21, 2011

@mcmire wrote:

@joliss Sorry to hijack this but I wonder if that section needs to be rewritten, again.

Right. I made a pull request at #577. Do you think that's better?

Collaborator

joliss commented Dec 21, 2011

@gorn wrote:

I use RoR and I somewhat did not pay attention that the README is NOT only for Rails so I did not even seeked for RoR section ;-)

Actually, I think a lot of people get tripped up by this and forget to
include 'capybara/rails'.

@jnicklas, back when you added rails.rb, was there something that
stopped you from autodetecting Rails (like defined? Rails.version)?

I'm thinking that we could require capybara/rails.rb at load-time for
Capybara, and wrap it in an if defined? Rails.version block.

One thing we'd have to deal with is deferring these lines in rails.rb
until the Rails app has been loaded, or Rails.root won't be defined:

Capybara.asset_root = Rails.root.join('public')
Capybara.save_and_open_page_path = Rails.root.join('tmp/capybara')
Collaborator

jnicklas commented Dec 21, 2011

The reason we don't autodetet Rails is because if defined?(Foo) is generally considered bad practice. Yehuda has written a couple of blog posts about this, and I agree with him. I don't think it's too much to ask of people to read through the README for a new project.

joliss added a commit to joliss/capybara that referenced this issue Dec 21, 2011

Collaborator

joliss commented Dec 21, 2011

The reason we don't autodetet Rails is because if defined?(Foo) is generally considered bad practice.

Well, now that you put it that way, yes, it seems like a really bad idea. :-)

Contributor

mcmire commented Dec 22, 2011

Right. I made a pull request at #577. Do you think that's better?

Yeah, much better :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment