Cover block: Add integration tests #45409
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glendaviesnz
added
[Type] Automated Testing
|
|
|
Size Change: +2.72 kB (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
glendaviesnz
force-pushed
the
add/more-cover-block-unit-tests
branch
from
f3bfcb5
to
cc6c4a1
Compare
|
Flaky tests detected in 8948961. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4526436094
|
glendaviesnz
force-pushed
the
add/more-cover-block-unit-tests
branch
from
1a26542
to
500cec3
Compare
kevin940726
reviewed
Mar 16, 2023
| const result = fn(); | ||
|
|
||
| // Advance all timers allowing store resolvers to resolve. | ||
| act( () => jest.runAllTimers() ); |
There was a problem hiding this comment.
An idea: Maybe in integration testing, we can opt-out of the act warning?
There was a problem hiding this comment.
I did try setting this var but it didn't get rid of the warnings - feel free to give it a try though, maybe I did something wrong.
…ync actions from Editor
glendaviesnz
force-pushed
the
add/more-cover-block-unit-tests
branch
from
e7db51d
to
d56dc26
Compare
|
@nerrad I was wondering if there was any value in this sort of approach for the likes of WooCommerce blocks (if you aren't already doing something similar) in which case maybe we should put the Integration Test Editor component somewhere that it can be imported by external projects? |
getdave
reviewed
Mar 17, 2023
getdave
reviewed
Mar 17, 2023
|
@getdave, @kevin940726 what do you think about merging this in its current form? I am sure it is something that is going to expand and develop further as we add more tests, but it seems to be in a stable/usable state as it is for now? Once it is merged in I will add some documentation - it will be easier to do that after this is merged so I can link to the relevant files in trunk. |
getdave
reviewed
Mar 22, 2023
kevin940726
reviewed
Mar 22, 2023
There was a problem hiding this comment.
I'm okay to try this but I'm also a bit worried that people would see this as the best practice and start copying the code while we're still fine-tuning this in different iterations. Should we add a "banner" comment to indicate that this is somewhat still experimental and documentation is still under development?
| await userEvent.clear( screen.getByLabelText( 'Left' ) ); | ||
| await userEvent.type( screen.getByLabelText( 'Left' ), '100' ); | ||
| // eslint-disable-next-line testing-library/no-node-access | ||
| const image = container.getElementsByClassName( |
There was a problem hiding this comment.
Why can't we use getByRole( 'img' ) for this?
There was a problem hiding this comment.
yeh, good point, had to add a within to get it to work as there is more than one img in the page, but have switched over.
| * For registering all the core blocks if needed as part of test setup. | ||
| */ | ||
| export function registerAllCoreBlocks() { | ||
| registerCoreBlocks(); |
There was a problem hiding this comment.
I'm wondering if we could do this in initializeEditor automatically?
There was a problem hiding this comment.
Yeh, I did start with that, but was thinking that at some point we might want to export this test editor setup from a package so that the likes of woo, and other 3rd party blocks could use it, and they may not want the core blocks loading.
There was a problem hiding this comment.
@kevin940726 I took another look at this and moved the block setup into initializeEditor and the teardown into an effect return in the editor, with a param to disable the creation of the core blocks if not needed. This will remove a bit of boiler plate from each of the test suites.
What do you think of this approach?
There was a problem hiding this comment.
@getdave you may want to take look at this change as well.
| @@ -70,7 +70,7 @@ function getInnerBlocksTemplate( attributes ) { | |||
| */ | |||
| const isTemporaryMedia = ( id, url ) => ! id && isBlobURL( url ); | |||
|
|
|||
| function CoverEdit( { | |||
| export function CoverEdit( { | |||
There was a problem hiding this comment.
Any reason why we can't use the default export?
There was a problem hiding this comment.
We actually don't need that export anymore - that was from some of my earlier experimentation - the default export was already used on the export with the withColors wrapper. Have reverted this now.
getdave
approved these changes
Mar 22, 2023
kevin940726
approved these changes
Mar 27, 2023
| ).not.toBeInTheDocument(); | ||
|
|
||
| // eslint-disable-next-line testing-library/no-node-access | ||
| const overlay = container.getElementsByClassName( |
There was a problem hiding this comment.
We still have class name selectors here (and a couple more below), do we also want to change these as well? Or is it a different case?
There was a problem hiding this comment.
I have updated the ones that related to the img but the remaining ones are just a span - I can't see another way of getting these other than adding a data-testid or something, so maybe we should leave them as is until there is a resolution to that question about whether they should be stripped from production code.
talldan
reviewed
Mar 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Adds a series of
Intergationtests to the Cover Block that test the Edit component, including the interaction between the Block Toolbar, the Inspector Panel and the Editor canvas.Why?
Currently, there is no way to test the edit flows of a block without using e2e tests. This reduces the level of test coverage that most blocks have as the addition of more e2e tests has an impact on PR CI job run times. Also, e2e tests have an increased likelihood of flakiness, reducing developer confidence in test runs, and a reluctance to add more.
As an indication of the potential speed advantage of running these tests at an integration rather than e2e level the two Cover block tests that I moved from the e2e tests took approx 6 seconds to execute as e2e, but approx 0.5secs as integration tests.
This doesn't remove the need for e2e tests as there are some things that can't be done at this level like uploading and manipulating images.
The idea is that if this approach is approved the Cover block could be used as a 'model' of Block level integration tests and the documentation updated to encourage more of this sort of testing as and when blocks are created, refactored, or regressions are fixed.
How?
This PR adds a lightweight Editor instance that can be rendered in jest and passed an array of blocks. The editor instance is then be manipulated using the
react-testing-library.Testing Instructions
Run:
Screenshots or screencast