Try: Storybook stories for blocks #39584
Closed
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
mikachan
added
[Focus] Accessibility (a11y)
|
Size Change: +660 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
|
I've just heard about @youknowriad's BlockBook, which I think is basically what I was aiming for here! |
|
yes, It needs some polishing (and updating, it's now a bit outdated) but yeah I think it would be great to integrate it here. Here's an old issue where I propose to do that. #24152 |
|
👋 I like the use of Storybook here, I think could be a nice debugging tool for manual testing! I'm not sure if I missing any steps but I'm getting errors when I want to run storybook locally. and I'm getting this: |
Looks like I introduced an eslint error in the story files! Does it work for you with the last commit? |
Yep! it's running fine now. 😺 As I said I think the use of storybook seems useful for manual testing but I think it doesn't seem to solve the automated report of a11y problems. Apart from that, I think there is a bigger challenge related to getting the final render of the block, especially the ones that involve server-side rendering that I think is missing here. I explored that issue and I think there is no easy way to get that apart from spinning up WordPress and actually rendering the blocks as we are doing here. |
My thinking was that we could use the Storybook URL as the target for automated tests, using a tool like
Yes, exactly! I think for the next steps I'd like to take a look at how BlockBook integrates themes (this already uses Twenty Nineteen and Twenty Twenty), and progress #24152 if possible. |
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? / Why?
This PR is an attempt to address an idea from the discussion in #39266 about improving the accessibility testing process for blocks.
#39437 is also a good attempt to improve this testing process, without using Storybook.
How?
I've added some functionality to the existing
full-contenttest suite, which generates story files for each block at the same time as the test fixture files are generated. The stories are saved instorybook/stories/blockswhich means they then appear in Storybook here:I think some blocks need to be excluded from Storybook, e.g. the template pattern block. I've started to handle this by creating an
excludedBlocksarray, but I haven't got any further with this yet.I'm not 100% convinced this is a good solution, but I thought I'd try it out anyway and share early for feedback.
My original reasoning behind this was:
jest-axe) and allows us to use it in manual testing.Some of my concerns are:
Testing Instructions
npm run fixtures:regenerate. The story files should be recreated successfully.npm run storybook:dev