WIP: Additional Gutenberg Support

[PypWalters]

Description of the Change

This proposes additional tools to make writing tests for blocks in the Gutenberg editor faster and easier, as well as a new set of standard tests that can be used for core blocks. This is a work in progress and there is much more that can be added, but I would like to get feedback on the approach and see if you are interested in this feature.

Alternate Designs

Benefits

• It will make it easier and faster to write block tests for Gutenberg
• Can provide easy to follow examples for testing blocks
• Helps to demonstrate the usefulness of wpacceptance to look for block regressions.
• This pairs very nicely with wpsnapshots in that you can make sure that block changes will not create validation errors on existing blocks.

Possible Drawbacks

Gutenberg is still very much in flux, so any functions using core Gutenberg classes for click events could change in future releases of core.

Verification Process

I have tested the new functionality locally and the tests pass. This should not introduce any regressions since it does not make any changes to existing functionality.

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Applicable Issues

Changelog Entry

[jeffpaul]

@PypWalters this would be pretty fantastic to get added in, what else do you feel is needed before this can get moved out of WIP?

[PypWalters]

@jeffpaul This would be different for different versions of Gutenberg because they have changed a lot of classes over time. So there is a lot of testing, and there are conditionals that would need to be put in place depending on WP version.

I am also interested in feedback regarding whether this is a good approach or whether there is anything else I should be considering.

[nicholasio]

@PypWalters I have been wanting to explore a different idea for testing Gutenberg blocks, but my idea would be to test them in isolation, outside of WordPress by rendering the block and the block editor separately and running the assertions against them.

This would work well for blocks that aren't dependent on WP stuff,

[jeffpaul]

@nicholasio that sounds a little bit like what @fabiankaegy has worked on extending BlockBook with his preliminary BlockGuide plugin that displays individual blocks outside the editor. Maybe some of what he's built there could be leveraged here?

[nicholasio]

@nicholasio that sounds a little bit like what @fabiankaegy has worked on extending BlockBook with his preliminary BlockGuide plugin that displays individual blocks outside the editor. Maybe some of what he's built there could be leveraged here?

Yeah but what he has done would still require WordPress in the mix, I was thinking of a testing strategy without WordPress.

[PypWalters]

@nicholasio With WPA you are already spinning up an environment to run tests on, if we tested blocks outside of WP would we need to spin up something else entirely?

[nicholasio]

@nicholasio With WPA you are already spinning up an environment to run tests on, if we tested blocks outside of WP would we need to spin up something else entirely?

Yes, one approach I'm thinking of is to just render Gutenberg in jsdom and run assertions with jest (and writing tests in javascript), on this approach we wouldn't need to spin up any environment making it much easier to run tests on CI (and much faster).

Another approach is to spin up a react application and run end-to-end tests with cypress or puppeteer.

I'm not sure how well those two approaches would work and also not sure about the limitations yet. I think truly e2e tests should still be considered though