Add content in migrate UI functional tests only when needed

Rerolled and added the fix in #42. Because there was no interdiff in #43 I started from #39. There were only entity count changes in the Upgrade6 and Upgrade7 test.

CC failure.

Remove lines from PHPStan baseline.

Changes to the entity counts in the forum tests.

So many rerolls!

#53 looks to be passing though so hopefully last one.

A simple reroll. As is often the case it was the migrate Upgrade tests.

Because the reroll was simple, I am restoring RTBC

The last submitted patch, 55: 3266491-55.patch, failed testing. View results →

Converted to an MR.

Hopefully MR reroll will be the last

This looks good but I think we need to sort out some cruftiness around \Drupal\Tests\migrate_drupal_ui\Functional\MigrateUpgradeTestBase::assertEmailsSent()

This removes the method and adds the email assertion to doUpgradeAndIncremental().

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily 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.

Feedback appears to be addressed I believe. Unless we need to actually deprecate assertEmailsSent() but not sure with module specific test bases.

Hiding patches for clarity

The recent changes look good - like where the asserting no emails have been sent has been added. One thing - I think we should deprecate the method before removing it because it is on a testbase class so part of the test API.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily 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.

So many rerolls sorry but can we open up 2 MRs now

1 for deprecation into 10.3.x
1 with those removals for 11.x

@smustgrave, when asking for work on an issue it is best to explain why that work is needed so we all understand what you are thinking. I see no reason for 2 MRs given that alexpott has agreed to remove the deprecation on commit.

However, I thought it best to check while I am here and it turns out the MR no longer applies to both 11.x and 10.3.x or 10.4.x due to changed int he phpstan baseline. I rebased 11.x and pushed that. Unfortunately, I can push to the branch I just created for 10.3. Yes, it is 10.3 not 10.4 like that name suggests.

The 10.4 MR is now really on 10.4, not 10.3 like I said earlier.

Unfortunately, I can't push to the branch I just created for 10.3. Yes, it is 10.3 not 10.4 like that name suggests.

Don't follow the MR is pointed to 10.4?

Isn't there suppose to be a deprecation?

I added some comments to MR 7882 (targeting 10.4.x). Some or all may also apply to MR 7261.

@quietone, can you explain in the issue summary what should be done with the two PRs? In particular, how do we end up with the deprecation notice in the correct branch or branches?

Please also check the CR and the deprecation notice to make sure that they reference the correct branches.

Is it too late to deprecate this method and remove it in the 11.x branch? Is it even in scope for this issue? If so, then please explain in the issue description. Or maybe it is in scope, but too late to remove it in 11.x, in which case it might be simplest to defer it to a follow-up issue.

The issue summary says something about the changes to the PHPStan baseline. I think that needs to be updated, at least for the 10.4.x branch.