Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include 'spec' directory into s.files #55

Closed
miyagawa opened this issue Feb 23, 2012 · 8 comments
Closed

Include 'spec' directory into s.files #55

miyagawa opened this issue Feb 23, 2012 · 8 comments

Comments

@miyagawa
Copy link
Contributor

I wonder if it is intentional that the 'spec' directory is excluded from the s.files in the gemspec. Probably these spec files were meant to be used only for testing on your development end, but I've found that some of the helpers and factories in the doorkeeper git repository are useful on my own app testing.

For example, i can use the Factory(:application) to create a new application, then use client_is_authorized to quickly create a new access token, then use with_access_token_header to send a new authorized request.

If they are installed in the gem install, we can load them using our own spec_helper by looking at Gem.loaded_specs and load from spec/support/helpers etc. What do you think?

@felipeelias
Copy link
Member

This seems a good idea. We should provide some test helpers, for sure.

But, by adding those test files to the gemspec wouldn't it require you to use FactoryGirl too? I mean, it does not seem a huge problem but maybe not everyone uses it.

@miyagawa
Copy link
Contributor Author

I understand the concern about the FactoryGirl, but i guess you can just ship it as it is and think about using other fixture frameworks other than factory_girl later?

Speaking of the dependencies, we've found that using Capybara for non-HTML based API testing gets a bit awkward as you need POSTing non-form data and sending request methods like DELETE or PUT, and that actually the developers do not recommend it. i.e. http://elabs.se/blog/34-capybara-and-testing-apis

I think these request spec helpers can be rewritten to use RackTest layer directly rather than mangling with Capybara's page.driver etc.

@felipeelias
Copy link
Member

Added to master.

Thanks for the tip regarding the specs, it makes much more sense. I'm already updating some of them.

jaimeiniesta pushed a commit to jaimeiniesta/doorkeeper that referenced this issue Mar 10, 2012
@jormon
Copy link
Contributor

jormon commented Dec 29, 2012

hey all, i'd really like to be able to use the factories in an application i'm building that uses doorkeeper, but i can't get the factories properly included. i've tried require 'doorkeeper/spec/factories/application' in my spec_helper.rb's RSpec.config block, but it errors out, not finding/loading the file... @miyagawa can you share how you did this above?

running with rails 3.8, rspec 2.11, doorkeeper 0.6.4

@miyagawa
Copy link
Contributor Author

@jormon I used to do something like below in my spec_helper:

doorkeeper_path = Gem.loaded_specs.find {|key, spec| key == 'doorkeeper'}.last.full_gem_path

%w(support/helpers factories).each do |helper|
  Dir.glob(doorkeeper_path + "/spec/#{helper}/*.rb").each do |file|
    require file.sub(/\.rb$/, '')
  end
end

but ended up copy-pasting the relevant factory and helper methods into our own managed files. It's arguably not ideal but works for us.

@jormon
Copy link
Contributor

jormon commented Dec 30, 2012

I ended up with this spectacular ugliness before I saw your reply :)

Dir["#{ENV['GEM_HOME']}/gems/doorkeeper*/spec/factories/*.rb"].each { |f| require f }

I think I will try and make a real patch to address this...

@jormon
Copy link
Contributor

jormon commented Jul 13, 2015

09cb679 breaks this (in 2.1.4+) if you have your own user factory

@jormon
Copy link
Contributor

jormon commented Aug 23, 2016

fixed in v4.2.0 which includes work done in #871

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants