Re: help with running tests for rails using gems
On 05/28/2013 02:27 PM, Praveen A wrote:
Hi,
I have been getting stuck trying to build many rails based gems,
shoulda-matchers - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709431
acts_as_api, nested_form etc I think they are too much dependent on
bundler and it is too complex to untangle the bundler dependency.
Basically, it is trying to find config/database.yml from
ruby-shoulda-matchers root where as it should be looking at the dummy
app creates at tmp/aruba/testapp
If anyone who is familiar with rails can guide me it would be really great.
Offlist, Praveen pointed me to
git://anonscm.debian.org/pkg-ruby-extras/ruby-shoulda-matchers.git
Running that, the current error is as follows:
/usr/bin/ruby1.9.1: No such file or directory -- /usr/bin/bundle (LoadError)
/usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
`gem_original_require': no such file to load -- bundler/setup (LoadError)
from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
`require'
from /ruby-shoulda-matchers/tmp/aruba/testapp/config/boot.rb:6
---
What's going on
shoulda-matchers is something that helps in the writing of tests of
Rails applications.
Rails is a framework that contains a generator that can produce
"scaffolding" which is a wired together application into which you can
insert your custom logic (models, views, controllers). Such
applications generally run tests.
shoulda-matchers has tests that verify that shoulda-matchers work. The
test that is failing starts by generating a default application using
Rails. Default applications generated by Rails depend on bundler. That
doesn't mean that they can't be changed after they are generated (the
scaffolding, after all is meant to be a starting point). It just means
that they start out with a dependency on bundler.
That dependency is in a file named boot.rb (you can see this name in the
stack traceback), as well as the fact that it is part of a "testapp".
The template that is used to create boot.rb itself is in Rails:
https://github.com/rails/rails/blob/3-2-stable/railties/lib/rails/generators/rails/plugin_new/templates/rails/boot.rb
At this point, we can fix the immediate problem by either changing Rails
to not generate apps that by default depend on bundler, or change
spec/spec_helper.rb in shoulda-matchers to pass --skip-bundle on the
rails new line, and then to modify the scaffolding to eliminate any
dependency on bundler.
Unfortunately, looking ahead, I found the following test:
---
When 'I generate a new rails application' do
steps %{
When I run `rails new #{APP_NAME}`
And I cd to "#{APP_NAME}"
And I comment out the gem "turn" from the Gemfile
And I comment out the gem "coffee-rails" from the Gemfile
And I comment out the gem "uglifier" from the Gemfile
And I reset Bundler environment variables
And I set the "BUNDLE_GEMFILE" environment variable to "Gemfile"
And I successfully run `bundle install --local`
}
if RUBY_VERSION >= '1.9.3'
append_to_gemfile %(gem 'rake', '~> 0.9')
step %(I successfully run `bundle update rake`)
end
end
---
Where we go from here...
Patching Rails to generate apps that don't, by default, use bundler will
still require changes to shoulda_matchers. It furthermore will cause
Rails to behave in ways different that it does in other environments.
Therefore, the right place to focus is on getting a version of bundler
which play's nice with Debian?
- Sam Ruby
Reply to: