Replace or enhance existing commands to take a programmatic approach

[Sidsector9]

Related #91

Is your enhancement related to a problem? Please describe.

Currently the commands we have take a UI approach. There are a few problems with this:

• UI navigation is slow
• Targeted HTML class names and IDs can change with WordPress versions, which means tests can fail on older WP versions.

We should avoid UI wherever possible. UI navigation should be for situations when we actually test UI features.
For example, to insert a paragraph block, instead of doing:

1. Click the inserter
2. Type in the name of the block
3. Click the block name
4. Type the paragraph content

We can directly call:

const paraBlock = wp.blocks.createBlock( 'core/paragraph', { content: '<CONTENT>' } );
wp.data.dispatch( 'core/editor' ).insertBlocks( paraBlock );

1. This will be a comparatively faster approach
2. Won't be affected by change of selectors in Block Editor
3. Reduce test sizes in most cases

We can also modify/create existing/new commands that can take both the programmatic and the UI approach as per requirement.

This was discussed previously but it was lost in comments:

#62 (comment)

@10up/open-source-practice would be great to hear your thoughts on this.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[Sidsector9]

Few commands that can be refactored:

1. openDocumentSettingsPanel()

This command can be refactored to:

function openDocumentSettingsPanel( panelName ) {
	if ( ! wp.data.select('core/edit-post').isEditorPanelOpened( panelName ) ) {
		wp.data.dispatch('core/edit-post').toggleEditorPanelOpened( panelName );
	}
}

2. openDocumentSettingsSidebar()

function openDocumentSettingsSidebar() {
	if ( ! wp.data.select('core/edit-post').isEditorSidebarOpened() ) {
		wp.data.dispatch('core/edit-post').openGeneralSidebar( 'edit-post/document' );
	}
}

This can be generalised even further by passing an argument to the function.

3. closeWelcomeGuide()

function closeWelcomeGuide() {
	if ( wp.data.select('core/edit-post').isFeatureActive( 'welcomeGuide' ) ) {
		wp.data.dispatch('core/edit-post').toggleFeature( 'welcomeGuide' );
	}
}

[peterwilsoncc]

I'm in two minds about this, as I see pros and cons.

The big pro is the one you identify, we don't see breaks due to changes within the block editor's UI that affect backward compatibility. Presuming backward compatibility is maintained by the block editor packages, we won't need to update the commands used in the Cypress utilities.

The cons I see are that we'll miss UI problems introduced by custom CSS/JS. When migrating the Distributor tests, I noticed that the E2E tests failed as our custom CSS was blocking access to the button for closing the welcome screen. By using the UI, I could introduce a quick fix.

On balance, I think it's probably safer to continue using the UI so we don't miss bugs with the Core code introduced via the plugin.