Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use BlockEdit for block rendering unit tests #29442

Closed
fluiddot opened this issue Mar 1, 2021 · 0 comments · Fixed by #29569
Closed

Use BlockEdit for block rendering unit tests #29442

fluiddot opened this issue Mar 1, 2021 · 0 comments · Fixed by #29569
Assignees
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Status] In Progress Tracking issues with work in progress [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@fluiddot
Copy link
Contributor

fluiddot commented Mar 1, 2021

What problem does this address?

Currently the unit tests related to rendering blocks are using the edit component of the different blocks. However the blocks are rendered in the editor through the BlockEdit component which includes a context with different properties like clientID that could be required by other logic from the blocks.

In fact, I realised when testing the changes that will introduce this PR, that rendering blocks without a clientId produce errors when running the unit tests, in this case the selector isBlockSelected which is heavily used in blocks returns true when the clientId is undefined.

What is your proposed solution?

My solution here is to add extra logic to the unit tests that renders blocks, first we should register the block as the editor does and then create a function that returns the BlockEdit component that will render the block we want to test.

Here is an example:

/**
 * Internal dependencies
 */
import { metadata, settings, name } from '../index';

/**
 * WordPress dependencies
 */
import { BlockEdit } from '@wordpress/block-editor';
import { registerBlockType, unregisterBlockType } from '@wordpress/blocks';

const Block = ( { clientId, ...props } ) => (
	<BlockEdit name={ name } clientId={ clientId || 0 } { ...props } />
);

describe( '<BLOCK_NAME> Block', () => {
	beforeAll( () => {
		registerBlockType( name, {
			...metadata,
			...settings,
		} );
	} );

	afterAll( () => {
		unregisterBlockType( name );
	} );

        it( 'renders without crashing', () => {
		const component = renderer.create(
			<Block />
		);
		const rendered = component.toJSON();
		expect( rendered ).toBeTruthy();
	} );
...
} );

As you can see, instead of rendering the Edit component of the block, we use the BlockEdit component by passing the block's name through the name prop and a default clientId.

@fluiddot fluiddot added the Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) label Mar 1, 2021
@hypest hypest added the [Type] Task Issues or PRs that have been broken down into an individual action to take label Mar 4, 2021
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Mar 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Status] In Progress Tracking issues with work in progress [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants