Update method name in HaveEnqueuedMail (job_match? to job_matches?) #2793
Conversation
| non_mailer_job = Class.new(ActiveJob::Base) do | ||
| def perform; end | ||
| def self.name; "NonMailerJob"; end | ||
| end |
There was a problem hiding this comment.
(Since now there are two specs in this file (i.e. the spec being modified here, and the new spec that I added above) that have occasion to refer to a non-mailer job class, I am extracting this previously anonymous/local job class up to an actual class constant defined in the setup at the top of this file. The downside of this is that the global Ruby namespace in specs is now polluted by an additional constant, NonMailerJob, but personally I think that's worthwhile, for the upside of any specs that need to reference such a job being able conveniently to do so.)
| it "passes when negated with 0 arguments and a non-mailer job is enqueued" do | ||
| expect { NonMailerJob.perform_later }.not_to have_enqueued_email |
There was a problem hiding this comment.
(This new spec fails without the job_match? => job_matches? rename done in this PR.)
|
For an earlier approved build (here) before I force-pushed a minor change or two, two matrix items failed:
However, these are also failing on |
I am pretty sure that these test failures are a result of the fact that Ruby 3.3.5 (released yesterday) is moving Also, I think that this has been somehow fixed in Rails's |
|
Good catch can you rebase this please |
This change fixes a bug wherein a spec that expects no mail to have been enqueued will fail (falsely claiming that a mail _was_ enqueued) if any _non-mail_ job is enqueued, even if indeed no _mail_ job is actually enqueued. This bug was introduced in ab6e6e8 / #2780 , which was first included in the 7.0.0 release. In that change, the `RSpec::Rails::Matchers::ActiveJob::Base` `job_match?` instance method was renamed to `job_matches?`. The problem is that `RSpec::Rails::Matchers::HaveEnqueuedMail`, which inherits from `RSpec::Rails::Matchers::ActiveJob::Base` (via `RSpec::Rails::Matchers::ActiveJob::HaveEnqueuedJob`), intends to override that method, which it does by defining its own `job_match?` instance method. However, because this `job_match?` method name is no longer the same as the (now so called) `job_matches?` method that it intends to override, the `job_match?` method of `RSpec::Rails::Matchers::HaveEnqueuedMail` is no longer having the intended override effect on the behavior of the matcher, producing the aforementioned bug. This change resolves the issue by updating the method name in the `RSpec::Rails::Matchers::HaveEnqueuedMail` subclass from `job_match?` to `job_matches?`, reflecting that renaming that was done in the parent class in ab6e6e8 .
|
@JonRowe Thank you for fixing the failing specs on I just rebased with latest |
|
Thanks, merged despite build failure as that has been fixed in #2798 |
…ethod-name Update method name in HaveEnqueuedMail (job_match? to job_matches?)
|
Released in 7.0.2 and 7.1.0 |
This change fixes a bug wherein a spec that expects no mail to have been enqueued will fail (falsely claiming that a mail was enqueued) if any non-mail job is enqueued, even if indeed no mail job is actually enqueued.
This bug was introduced in ab6e6e8 / #2780 , which was first included in the 7.0.0 release.
In that change, the
RSpec::Rails::Matchers::ActiveJob::Basejob_match?instance method was renamed tojob_matches?. The problem is thatRSpec::Rails::Matchers::HaveEnqueuedMail, which inherits fromRSpec::Rails::Matchers::ActiveJob::Base(viaRSpec::Rails::Matchers::ActiveJob::HaveEnqueuedJob), intends to override that method, which it does by defining its ownjob_match?instance method. However, because thisjob_match?method name is no longer the same as the (now so called)job_matches?method that it intends to override, thejob_match?method ofRSpec::Rails::Matchers::HaveEnqueuedMailis no longer having the intended override effect on the behavior of the matcher, producing the aforementioned bug.This change resolves the issue by updating the method name in the
RSpec::Rails::Matchers::HaveEnqueuedMailsubclass fromjob_match?tojob_matches?, reflecting that renaming that was done in the parent class in ab6e6e8 .