Add tests of new release emails

Shouldn't these fail until 🐛 Links broken in new releases email Needs work is merged?

No. This is testing the existing email message.

In that case test looks good.

The last submitted patch, 2: 3276953-2.patch, failed testing. View results →

Random test failure.

1) Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockPrivateFilesTest::testPrivateFiles
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "files[settings_block_form_field_file_0]" not found.

Text change needed due to 🐛 Do not use verb "Install" for things other than turning on modules/themes Fixed .
The interdiff was made with the option, --colour-words.

Restoring status.

The last submitted patch, 10: 3276953-10.patch, failed testing. View results →

Random failure

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I swapped out withConsecutive() for willReturnOnConsecutiveCalls().

Based on the comment at #3306554-24: InvocationMocker::withConsecutive() is deprecated in PHPUnit 9.6 and removed from PHPUnit 10 → , I don't think that replacing with willReturnOnConsecutiveCalls() is the long term solution.

What about using will($this->returnValueMap(? I have updated the MR with that idea, plus some other improvements.

Just copying over comment from the other issue

@longwave

Discussed this again with @mondrake in Slack. We now think that just replacing withConsecutive with willReturnOnConsecutiveCalls is not really the right thing to do - these two are not equivalent, and it just happens that here the return values probably don't matter so the tests happen to pass, but we have not made the correct change.

@quietone's solution appeared to work and believe covers the same as what withConsecutive() did. The other issue used a custom callBack but not sure that applies here.

New test coverage for something previously untested is always nice. The new code looks good to me and I can't think of anything else to add.

Committed and pushed 4f726e041b to 11.x and beedcb6bde to 10.2.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.

quietone → closed merge request !4654