Testing: Add E2E test for inserting reusable blocks by inserter after page refresh

[aduth]

To avoid repeated regressions, we should include an end-to-end test for inserting a reusable block by Inserter in a fresh editor page. See #9962 (comment) .

Original Regression:

---

Describe the bug

Reusable blocks are not shown in the Inserter.

To Reproduce

1. (Prerequisite) Create a reusable block in a Gutenberg editor session
2. Create a new post
3. Try to insert the reusable block (either one preexisting, or the one created in Step 1) using the Inserter.
4. Observe that the reusable block is not shown in the inserter.

Expected behavior

Reusable block is both shown and searchable.

Additional context

Slack mentions:

• https://wordpress.slack.com/archives/C02QB2JS7/p1537090223000100
• https://wordpress.slack.com/archives/C02QB2JS7/p1537090223000100

From @youknowriad:

I think we do have an e2e test, what's missing is an e2e test inserting a reusable block after refreshing the page.

[aduth]

Workaround: The reusable blocks appear correctly when the Inserter is closed and reopened again. It appears to hint to a possible race condition on this logic:

gutenberg/packages/editor/src/store/effects/reusable-blocks.js

Lines 55 to 60 in 0816e23

	// TODO: these are potentially undefined, this fix is in place
	// until there is a filter to not use reusable blocks if undefined
	const postType = await resolveSelector( 'core', 'getPostType', 'wp_block' );
	if ( ! postType ) {
	return;
	}

cc @youknowriad Does any of this sound familiar? Perhaps related to recent work in #9732?

[aduth]

I'd suggest we approach this from a TDD angle, updating the E2E reusable block insertion case to a failing state and working backward to a resolution. Based on the above workaround, I expect it may start failing if we ensured a fresh post for each test case run, i.e. using beforeEach instead of the current beforeAll (cc @noisysocks).

[youknowriad]

the recent changes have been merged after the 3.9 RC, so while it's related, I think the issue was there before.

[aduth]

I checked out a detached head at both 41d4223 and 41d4223~1 and it worked in both cases, which led me to believe that it might not have been directly related to #9732, but became introduced afterward.

[youknowriad]

Oh sorry, I'm tired, I thought you were linking to the resolvers refactoring that was recently merged. I can take a look at this issue tomorrow hopefully.

[aduth]

Reopening as we should have an end-to-end test.

[youknowriad]

I think we do have an e2e test, what's missing is an e2e test inserting a reusable block after refreshing the page.

[aduth]

Yes, the test was obviously not solid enough, based on the presence of the bug. I'd say in general we should have each and every test case working from a new post†.

† I think there's still some room to optimize here, if performance is a concern. Artificially resetting the editor state to its initial value without actually triggering a reload.

[tellyworth]

Based on the above workaround, I expect it may start failing if we ensured a fresh post for each test case run, i.e. using beforeEach instead of the current beforeAll (cc @noisysocks).

Experimenting with this, we've encountered some other issues to do with tab focusing that interfere with the tests. Tab behaviour is different when starting with a new post for unknown reasons. We're investigating that further.