Usually users extends tests classes doing something like:
ActionView::TestCase.include MyCustomTestHelpers
This is bad because it will load the ActionView::TestCase right aways
and this will load ActionController::Base making its on_load hooks to
execute early than it should.
One way to fix this is using the on_load hooks of the components like:
ActiveSupport.on_load(:action_view) do
ActionView::TestCase.include MyCustomTestHelpers
end
The problem with this approach is that the test extension will be only
load when ActionView::Base is loaded and this may happen too late in the
test.
To fix this we are adding hooks to people extend the test classes that
will be loaded exactly when the test classes are needed.
This will fix issues in [resque-scheduler](https://github.com/resque/resque-scheduler) `#job_to_hash` method,
so we can use `#enqueue_delayed_selection`, `#remove_delayed` method in resque-scheduler smoothly.
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
test.
This PR adds a method called `queue_adapter_for_test` to
`ActiveJob::TestHelper`. This method is expected to provide the queue
adapter to be used for jobs under test. It maintains the current
behaviour by defaulting to an instance of
`ActiveJob::QueueAdapter::TestAdapter`. Tests that include
`ActiveJob::TestHelper` or extend from `ActiveJob::TestCase` can provide
a custom queue adapter by overriding `queue_adapter_for_test` in their
class.
Taken literally, the documentation suggests that the callback gets
called twice (before and after enqueueing). By wording it similarly to
that of around_perform this confusion is avoided.
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
Follows the same pattern as controllers and jobs. Exceptions raised in
delivery jobs (enqueued by `#deliver_later`) are also delegated to the
mailer's rescue_from handlers, so you can handle the DeserializationError
raised by delivery jobs:
```ruby
class MyMailer < ApplicationMailer
rescue_from ActiveJob::DeserializationError do
…
end
```
ActiveSupport::Rescuable polish:
* Add the `rescue_with_handler` class method so exceptions may be
handled at the class level without requiring an instance.
* Rationalize `exception.cause` handling. If no handler matches the
exception, fall back to the handler that matches its cause.
* Handle exceptions raised elsewhere. Pass `object: …` to execute
the `rescue_from` handler (e.g. a method call or a block to
instance_exec) against a different object. Defaults to `self`.
- [ci skip] Active Job Async doesn't support to Async feature as per it's definition.
- [ci skip] Active Job Async doesn't support to Async feature as per it's definition.
- [ci skip] Active Job Async doesn't support to Async feature as per it's definition.
- [ci skip] Active Job Async doesn't support to Async feature as per it's definition.
ActiveJob jobs now inherit from ApplicationJob by default.
However, when updating to Rails 5 from the old Rails,
since there is a possibility that ApplicationJob does not exist.
Placing non-native JSON data types, like symbols, in the hash to serialize means that the deserialize method will return something different from what was serialized, a common bug and source of frustration for devs.
