I have a gem installed on my rails 3 application that runs smoothly, But when I run the cucumber tests, that gem is missing to get the user atributes. And actually it is the way it should be because of the security management. ( no login == no information )
So, I am wondering if there is any way to disable this gem while I am running the cucumber test ? so that i get no error based on this gem.
thanks in advance !
In your gemfile, you can add the gem in a particular environment. i.e.
group :development, :production do
gem 'yahoo-weather'
end
This gem will only be added in the development and production env only. It wont be present in the testing environment.
After checking the problem with my colleague, we decided on the solution that seems almost OK to do it in this way,
Since we dont want the specific gem function to get into play during the test process, we decided to use
acts_as_specificgem(do this do that) unless Rails.env == "test"
No need to repeat ourselves at test scenarios and looks more clean.
cheers!
Related
I am writing a gem that can be used with both Sinatra and Rails, however, the gem dependencies are different based on which framework the developer is using the gem on.
If it's a rails app, we need 'sass-rails' and 'coffee-rails'
If it's a sinatra app, we need 'sass' and 'coffee-script'
Ideally bundler would just install the necessary gems based on which framework this gem is being loaded into, but I can't seem to figure out how to conditionally specify dependencies.
Any suggestions would be much appreciated.
I would suggest you not to do that. It would be hackish and unreliable.
What you can do however is divide and conquer! Build a generic version of your gem that is framework agnostic and only handles the logic, let's call it yourgem-core, then you can build two other gems based on that first one, called yourgem-rails and yourgems-sinatra.
It's much better, only logic and logic test in yourgem-core, only rails integration tests in yourgem-rails, only sinatra integration tests in yourgem-sinatra
You can use :group option in bundler.
Reference: http://bundler.io/v1.5/groups.html
I'm building an engine, and I want to use VCR and Webmock for testing.
The documentation within the Gemfile generated when an engine is created, seems to suggest that all an engine's gems should be loaded via gemspec, but the only options for this are add_dependency and add_development_dependency. If I use the latter, VCR and Webmock get loaded into my development environment, and I then have to explicitly disable Webmock in the development environment. I'd rather not do that as a host app may want these gems to work in development, and my engine disabling them may be unexpected.
The obvious solution would appear to be to use the engine's Gemfile:
group :test do
gem 'vcr'
gem 'webmock'
end
Is this the right way to load gems that are only used when testing an engine?
Are there any gotchas doing this?
One of the well known rails engines, rails_admin (https://github.com/sferik/rails_admin) uses that approach, so I believe it can be considered a good practice.
What's the load order for Rails app and Rails app's Rails Engines?
My guess is that the Rails app Gemfile is the determining factor for a gem being loaded or not loaded. This might be worth a try in a Rails test app.
I believe the answer is that there is nothing wrong with declaring in an engine's Gemfile, gems only used for testing and debugging the engine code. Further, I think the Gemfile template should be made less ambiguous, and have submitted a pull request to this effect:
https://github.com/rails/rails/pull/11881
i want to debug ROR without going through the effort of putting inspect method for every relevant object in the controller as well in the model.is there a better way as we have in Java (Run time debugger using eclipse).i know that I can Use Rails.logger and also make use of rails Console(irb`).i am even aware of debugging/inspecting elements in erb/rb file.Still is there a better,quick and reliable way to debug a Rails app.
There is much better, see this railscats.
It presents two great gems, especially Better Errors
Otherwise, you could use pry with rails, see this railscast.
you can also use pry-rails, pry-debugger and then use binding.pry method in your code and then while using your app you have Rails console available in rails server
Add this lines to your application's Gemfile
group :development do
gem 'ruby-debug19'
end
then run cammand
bundle install
add debugger within your controller or model method, stop the rails server and restart again. Whenever rails found word debugger it stops control at that point. You can easily debug your value or object.
Hope this will helps you.
I'm writing some automated tests for an app using rails 3.1. One of my tests is failing and at the point of failure I want to be able to jump into the rails console and inspect the state of things. Leading up to this assertion a lot of objects were created and states were changed.
After the test suite finishes running the test database is cleared.
I remember there was some way to insert a breakpoint in the test file or something similar which would throw me into the console. I've done a ton of googling and can't find it.
Anyone?
Require ruby-debug on your Gemfile.
If on 1.8:
gem 'ruby-debug'
If on 1.9:
gem 'ruby-debug19', :require => 'ruby-debug'
Note that if you're on 1.9.3 requires a few tweaks.
Finally, put a debugger statement where you want to debug, and run your tests. It should popup a console.
I'd also recommend taking a look at pry, as Amadan stated.
Use Pry, and say binding.pry as a breakpoint.
You might like this Railscast.
If a gem has rails dependencies, do you think it is better to write the gem tests in a way they can be run standalone or run them under a rails project?
A gem should be a piece of code which acts stand-alone. Otherwise it is part of the application, so the tests should be created stand-alone as well. In this way others (hypothetically) can perform the tests as well. If the tests depend on your application others cannot test your gem.
Furthermore when you want to test your gem it should not fail because your application is failing. After your gem passed the test, you can test the application knowing that your gem is functioning well (assuming that you tested everything).
Whether the gem is depending on Rails or not is not an issue, since Rails also has been tested (and you can assume it is working properly). So these dependencies do not (/should) influence your gem.
I'd say it depends on the kind of dependencies the gem needs. Eg. if it's just the ActiveRecord it's quite easy to include it into your test suite. In more complex cases you can always mock some of the needed functionality. In a really complex cases, creating a test app is better than nothing (IMO).