Implement send_email matcher

[ka8725]

Currently, it already has a have_enqueued_mail matcher, but it's too low-level, requiring attention to details such as job name, mailer name, queue, and so on. While all of that information can be useful, from a business perspective, it's rarely necessary. This suggested matcher aims to improve the situation so that when you use it, you can focus on what matters, such as 'an email with a specific subject and specific text within the body being sent'.

Examples:

@example Positive expectation
  expect { action }.to send_email

@example Negative expectations
  expect { action }.not_to send_email

@example More precise expectation with attributes to match
  expect { action }.to send_email(to: 'test@example.com', subject: 'Confirm email')

Originally that was a gist: https://gist.github.com/ka8725/6053d55be74f15b53cabfc3ac4dc99df

A related LinkedIn post - https://www.linkedin.com/feed/update/urn:li:activity:6990304469477429248?utm_source=share&utm_medium=member_desktop

TODO

• find a way to surface better the multiple email failure case especially as if you don't match say, subject, you could easily trigger it

[pirj]

Nice!

[pirj]

A feature spec would be helpful to make this more discoverable.

[JonRowe]

Thanks for this, it mostly looks great just some readability tweaks, I'm also wondering if theres a way to surface better the multiple email failure case especially as if you don't match say, subject, you could easily trigger it

[ka8725]

I don't like this idea actually, Rubocop is right - https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/ConstantDefinitionInBlock

Defining classes with let also complicates things.

Classes should be defined within modules. Moving it out to a shared module.

[ka8725]

@JonRowe to address this point:

find a way to surface better the multiple email failure case especially as if you don't match say, subject, you could easily trigger it

I have an idea to inspect the sent emails. 0e25b66 That should give a clue for devs where the failure comes from. Ideally, that would be great to inspect the body as well, but the output can be very huge. Therefore, I would better not do that. Basically, having just the subject inspected would suffice, but the other important attributes like from/to not hurt.

[pirj]

Looks great!
A few nitpicks below.

[pirj]

Thank you so much for the idea and for implementing it!

[ka8725]

@pirj can the failed CI job be restarted? looks like there was a network issue - https://github.com/rspec/rspec-rails/actions/runs/4790425603/jobs/8522781666?pr=2670

Addressed

[pirj]

Green. It slipped my mind, do we squash commits in meaningful ones before merging?

[ka8725]

@pirj I've squashed them.

[ka8725]

@JonRowe all things are polished in my opinion, is there something else I can improve in this PR?

[JonRowe]

Just a couple of wording tweaks to the feature, and this is good to go, sorry for the delayed review.

[JonRowe]

Merged in 69c09bc thanks for the hard work on this.

[JonRowe]

Released in 6.1.0 apologies for the delay