Update experimental features tests

[deBhal]

NOTE: This PR is currently targeted at the add/experimental-block-patterns-tests branch from #48032. Once that PR is merged, we'll rebase against that new trunk instead.

This PR is a followup to #48032 that fixes the experimental features tests and combines the experimental data tests introduced in #48032 together with them in the one file.

There were a few things that were preventing the experimental feature tests from running successfully:

• The tests need the @parallel tag to get picked up on CircleCI (although they run fine locally without them)
• The javascript passed to the selenium driver.executeScript() needs a return statement. The driver was returning null no matter what happened in the test environment, leading to false positives.
• A typo that caused another assert to always pass.

After fixing those, we still see a failure with '__experimentalMainDashboardButton', and I think this might be a legitimate failure, as I can't see interface or __experimentalMainDashboardButton on the global wp property in the editor.

Testing instructions

You can re-trigger the tests to run on CircleCI by removing and re-adding the [Status] Needs e2e Testing label, but if you want to test changes there (like removing the failing check to test the rest) you'll need to push a new branch and add the label there.

You can also run the tests locally from the test/e2e directory in calypso using something like:
env BROWSERSIZE=desktop npx mocha specs/wp-gutenberg-experimental-features-spec.js
(You may or may not need some config decryption magic as described in the Field guide "Automated end-to-end Testing" page)

Also fixes #47839.

[matticbot]

Test live: https://calypso.live/?branch=fix/experimental-features-test

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[deBhal]

Intentional failures show up in https://app.circleci.com/pipelines/github/Automattic/wp-e2e-tests-for-branches/50286/workflows/0d8b070c-3749-4515-ac3b-56ea86e8bea7/jobs/125901 (It actually occurs three times because we've configure 3 tries before giving up):

[deBhal]

@p-jackson: Is wp.interface being null a legitimate test failure?

[p-jackson]

Good find! I think these tests have been broken but since it didn't have the @parallel we didn't notice!

There's actually no such thing as wp.interface at runtime; the @wordpress/interface package is bundled at build time, it doesn't expose itself as a global. So the __experimentalMainDashboardButton test isn't actually appropriate for this e2e. (at least until Gutenberg 9.5 when the experimental feature moves to another package, but that's not being addressed in this PR)

The __experimentalMainDashboardButton case is being tested in this unit test: apps/editing-toolkit/editing-toolkit-plugin/wpcom-block-editor-nav-sidebar/src/test/attach-sidebar.test.ts

I think the best course of action is just to delete the @wordpress/interface entry from the EXPERIMENTAL_FEATURES object.

[p-jackson]

Yep, just found the line was added in #47712 but CI would have never run the test.

[matticbot]

Caution: This PR affects files in the Editing Toolkit Plugin on WordPress.com
Please ensure your changes work on WordPress.com before merging.

D54345-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing the Editing Toolkit Plugin for more info: PCYsg-ly5-p2

[deBhal]

I've been trying to figure out why editSite is not is not there, and while it's still a mystery, It does seem to be a legitimate failure - there's no wp.editSite in the editor contexts I've checked.

I tried to figure out how that global wp site gets populated, but failed to penetrate the magic. @wordpress/edit-post does get added to the global object, but @wordpress/edit-site doesn't, and I can't see the difference or find where it's specified.

The actual target property seems odd too. The version of edit-site that we're pulling (v1.15.6) in doesn't expose the property, but the latest gutenberg master verstion is up to v1.16, and it does expose it, so maybe we're ahead of the curve rather than behind?

Also weird: We use the property in apps/wpcom-block-editor/src/calypso/features/iframe-bridge-server.js, but when I dumped out the editSitePackage property at run-time it was null. I wonder if this is related to the npm package magic that we use - there's no edit-site package in apps/wpcom-block-editornode_modules, it pulls in the version from the calypso root, and I wonder if the the require() call is unaware of this magic.

Anyway, I've spent way too much time trying to figure this out already, so for this PR I'm just dropping the line. I'll create an issue with these findings and see if I can find someone to pick it up.

[ramonjd]

✅

Ran locally as well:

    ✓ Can log in (29467ms)
    Can find experimental package features
      ✓ "blockEditor" package should be available in the global window object
      ✓ __experimentalBlock should be available in @wordpress/block-editor
      ✓ __experimentalInserterMenuExtension should be available in @wordpress/block-editor
      ✓ "date" package should be available in the global window object
      ✓ __experimentalGetSettings should be available in @wordpress/date
      ✓ "components" package should be available in the global window object
      ✓ __experimentalNavigationBackButton should be available in @wordpress/components
    Experimental data we depend on is available
      ✓ is iterable: wp.data.select( 'core/editor' ).getEditorSettings().__experimentalBlockPatterns


  9 passing (32s)

[deBhal]

I've popped my notes from trying to figure out the edit-site thing into #48585