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

Reusable Blocks: Move E2E tests setup logic to a beforeAll() #21249

Closed
noisysocks opened this issue Mar 30, 2020 · 2 comments
Closed

Reusable Blocks: Move E2E tests setup logic to a beforeAll() #21249

noisysocks opened this issue Mar 30, 2020 · 2 comments
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. [Type] Code Quality Issues or PRs that relate to code quality

Comments

@noisysocks
Copy link
Member

noisysocks commented Mar 30, 2020

The tests in packages/e2e-tests/specs/editor/various/reusable-blocks.test.js have an assumed order which is incorrect as tests should be able to run independently of one another.

From #7947 (comment):

There should ideally be no concept of "above" as assuming tests to be run in particular order (or even that any others are run at all). I should be able to change this to it.only and the test should be fine to run in isolation. Common behaviors should be established in lifecycle (beforeEach or beforeAll) or repeated in every test case.

Note: I'm encountering this in implementing a new end-to-end test case for verifying the fix at #21205. Ideally I'd like to iterate on the test case with it.only, but at least as currently presented, there's no prior art for me to leverage commonly available reusable blocks to work with. For the purposes of my test, I might just copy the logic from "can be created" to create the reusable block. It could be straight-forward enough to refactor to its own function; not sure if I'll do that or end up just following the pattern here of reusing the block created in an earlier test case once finished.

@noisysocks noisysocks added Good First Issue An issue that's suitable for someone looking to contribute for the first time [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. Needs Dev Ready for, and needs developer efforts [Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) [Type] Code Quality Issues or PRs that relate to code quality labels Mar 30, 2020
@noisysocks
Copy link
Member Author

As part of this refactor we can remove the 'can be inserted after refresh' test added in #20605 as it is redundant if the 'can be inserted' test begins from a clean slate.

@sainthkh sainthkh added the [Status] In Progress Tracking issues with work in progress label Apr 30, 2020
@youknowriad
Copy link
Contributor

I did an extensive refactor to this test a few weeks ago and I believe it's now based on independent tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Synced Patterns Related to synced patterns (formerly reusable blocks) Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Automated Testing Testing infrastructure changes impacting the execution of end-to-end (E2E) and/or unit tests. [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants