I am upgrading a Rails 2 to Rails 3 application (code not written by me). The (well tested code) uses shoulda and Test::Unit, and extensively uses the macros should_create and should_change.
I understand from this discussion that the shoulda maintainers want to get rid of both methods but that people using Test::Unit don't find it necessary (not sure I am grasping the whole discussion though).
Anaway, is there a way to selectively turn of the deprecation warnings for specified macros? I already know from this posting that you can turn off the deprecation warnings in the Rake test output entirely by setting:
ActiveSupport::Deprecation.silenced = true
in your the test environment file and I also know that you can put specific pieces of code in a block to get them silenced:
ActiveSupport::Deprecation.silence do
# no warnings for any use of deprecated methods here
end
The latter is an option but would require me to go over all the tests and enclose the should_create macros in such a block. So I was wondering there was a way to eliminate warnings for specific macros entirely with one configuration setting?
In Rails, all deprecation warnings start with DEPRECATION WARNING:, so you can search for that string in your logs. When it comes to production, the easiest way to discover deprecation warnings is by using a monitoring tool (like Honeybadger or Airbrake ).
Keep in mind that sometimes deprecation warnings can also happen inside gems. That usually happens when the gem has rails as a dependency and uses deprecated code in it. If that’s the case you should consider upgrading that gem.
That usually happens when the gem has rails as a dependency and uses deprecated code in it. If that’s the case you should consider upgrading that gem. Once the changes are done, run the appropriate specs or manually test the parts that were modified to make sure that everything works normally.
There are a few different ways to find deprecation warnings in your application. If you have good test coverage, you can run the whole test suite and look at the logs that were generated. If you are using a CI service (like CircleCI or Travis CI) you can easily see the logs once the build finishes running.
Old question - but if you have new depreciations you'd like to selectively ignore:
ActiveSupport::Deprecation.behavior = lambda do |msg, stack|
unless /LIBRARY_NAME/ =~ msg
ActiveSupport::Deprecation::DEFAULT_BEHAVIORS[:stderr].call(msg,stack) # whichever handlers you want - this is the default
end
end
This is for ActiveSupport 3.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With