This pattern is pretty common:
```ruby
assert_emails 1 do
post invite_user_path # ...
end
email = ActionMailer::Base.deliveries.last
assert_equal "You were invited!", email.subject
```
We can make it a bit nicer, by returning the email object from `assert_emails`. This is similar to how `assert_raises` returns the error so you can do additional checks on it. With this PR:
```ruby
email = assert_emails 1 do
post invite_user_path # ...
end
assert_equal "You were invited!", email.subject
```
If a single email is sent, a single `Mail::Message` is returned. If multiple emails were sent, an array is returned.
```ruby
emails = assert_emails 2 do
post invite_user_path # ...
end
emails.each do |email|
assert_equal "You were invited!", email.subject
end
```
The default is set to 5 and only applied for new applications or
applications that opt-in for this new default.
Closes#42089.
[André Luis Leal Cardoso Junior + Rafael Mendonça França]
This reverts commit 0f9249c93f.
Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
- If a Mail defines a custom delivery_job, all ActionMailer assertion
helper (assert_emails, assert_enqueued_emails ...) wouldn't work.
```ruby
MyMailer < ApplicationMailer
self.delivery_job = MyJob
end
# This assertion will fail
assert_emails(1) do
MyMailer.my_mail.deliver_later
end
This PR leverage the new ActiveJob feature that accepts Procs for the
`only` keyword and check if the delivery job is one of ActionMailer
registered ones.
Setting parameterized_delivery_job on a mailer class will cause Parameterized::MessageDelivery to use
the specified job instead of ActionMailer::Parameterized::DeliveryJob:
class MyMailer < ApplicationMailer
self.parameterized_delivery_job = MyCustomDeliveryJob
...
end
Example of `assert_enqueued_with` with no block
```ruby
def test_assert_enqueued_with
MyJob.perform_later(1,2,3)
assert_enqueued_with(job: MyJob, args: [1,2,3], queue: 'low')
MyJob.set(wait_until: Date.tomorrow.noon).perform_later
assert_enqueued_with(job: MyJob, at: Date.tomorrow.noon)
end
```
Example of `assert_enqueued_email_with` with no block:
```ruby
def test_email
ContactMailer.welcome.deliver_later
assert_enqueued_email_with ContactMailer, :welcome
end
def test_email_with_arguments
ContactMailer.welcome("Hello", "Goodbye").deliver_later
assert_enqueued_email_with ContactMailer, :welcome, args: ["Hello", "Goodbye"]
end
```
Related to #33243
* ActionMailer::Base can unregister observer(s) and interceptor(s).
One or multiple mail observers can be unregistered using
`ActionMailer::Base.unregister_observers` or
`ActionMailer::Base.unregister_observer`.
One or multiple mail interceptors can be unregistered using
`ActionMailer::Base.unregister_interceptors` or
`ActionMailer::Base.unregister_interceptor`.
For preview interceptors, it's possible to use
`ActionMailer::Base.unregister_preview_interceptors` or
`ActionMailer::Base.unregister_preview_interceptor`.
* Ensure to be reset registered observer(s) and interceptor(s)
* Add explanation to CHANGELOG
* Add original author's name
[Kota Miyake + Rafael Mendonça França + Claudio Ortolina]
* Eager autoload mail gem when eager load is true
We had a production issue where our Sidekiq worker threads all became
deadlocked while autoloading a file within the mail gem, required via
ActionMailer, despite setting our Rails applicaiton to eager load.
`Mail.eager_autoload!` exists and works great, ActionMailer just doesn't
call it during eager loading. Adding it to the ActionMailer Railtie's
eager_load_namespaces takes care of calling `Mail.eager_autoload!`
during the `eager_load!` initializer.
* 'Mail' isn't defined yet, use before_eager_load instead
* Make sure mail is loaded
* Move eager load of Mail into ActionMailer.eager_load!
[Samuel Cochran + Rafael Mendonça França]
PR #29270 changed the number of arguments that gets passed to Procs
defined in ActionMail::Base.default. With this changeset, Procs can
now have 1 or 0 arguments
Also adds test coverage for AM::Base.default Proc arity.
Setting delivery_job on a mailer class will cause MessageDelivery to use
the specified job instead of ActionMailer::DeliveryJob:
class MyMailer < ApplicationMailer
self.delivery_job = MyCustomDeliveryJob
...
end
Alex Ghiculescu