I use a lot the have_enqueued_job matcher because I like its syntax and it also perform params serialization that allows me to catch invalid arguments given to background jobs such as symbol serialization.
However I think that it's a little bit too verbose when used with ActionMailer::DeliveryJob e.g.
expect {
subject.perform request
}.to have_enqueued_job(ActionMailer::DeliveryJob).with(
'SubscriptionMailer',
'welcome',
'deliver_now',
hash_including('email_address' => email),
'en'
)
It would be very nice to have a specialized wrapper around it, something like this
expect {
subject.perform request
}.to have_enqueued_email(SubscriptionMailer, :welcome).with(hash_including('email_address' => email), 'en')
What do you think?
This sounds like the perfect excuse to write a little extension gem
Hey, not sure if this is helpful or too late, but I have made gem that provides a matcher for deliver_later. The gem is called deliver_later_matchers.
GitHub: https://github.com/jdlubrano/deliver_later_matchers
Rubygems: https://rubygems.org/gems/deliver_later_matchers
This can be done with a matcher. Please look at https://github.com/rspec/rspec-rails/issues/1849#issuecomment-363942904
@JonRowe do you think we should close this issue?
No, I feel as we have enqueued job matchers, and ActiveMailer uses active job, this is something we should consider, @jdlubrano would you care to submit a PR with your changes rolled into ours?
@JonRowe
Thank you for reaching out; I would be delighted to submit a PR. Have you had a chance to look at the deliver_later_matchers gem's API? Do you want to use the same API in rspec-rails or did you have something else in mind?
Yes I have, it looks very similar to our job matchers on the outside and inside, it would be great to leverage our existing job innards if possible (legitimate case for inheritance woo!)
Personally I would make have_enqueued_mail the primary interface, and have the other two as aliases as you wish :)