-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Testing: Skip unreliable end-to-end tests #15059
Conversation
@@ -30,7 +30,7 @@ describe( 'block deletion -', () => { | |||
beforeEach( addThreeParagraphsToNewPost ); | |||
|
|||
describe( 'deleting the third block using the Remove Block menu item', () => { | |||
it( 'results in two remaining blocks and positions the caret at the end of the second block', async () => { | |||
it.skip( 'results in two remaining blocks and positions the caret at the end of the second block', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one I'm hesitant because in my experience at least it has shown to be unreliable only when using "popular plugins" and the fact that the popular plugins test didn't prove to be succesful IMO, I wonder if we should remove those instead.
I’m coming to the conclusion that we should skip all tests that will fail a given number of times on Travis in a week or similar period. Review all of them, open issues if those failures are legitimate and included test’s source code as an example. Once it’s done we should remove all skipped tests. |
Yes, I think this is all important, that (a) tests are reliable and (b) we commit to returning these to be unskipped.
I hesitate here because I'm sure to abandon the plugins testing altogether as these issues, when present, could likely be legitimate. But I agree that they make debugging more difficult, and haven't provided very much value overall. To @gziolo 's point, I'm also considering to not put much thought into being bogged down to how specifically we decide to skip tests and just opt to skip indiscriminately, and evaluate options afterward. I've spent some time debugging this specific failure. In doing so, I observe the tedium of debugging on behalf of these other popular plugins (and not knowing which specific one could be a culprit). One lead I have is in the fact that you can observe in standard use of the block settings menu, the "Convert to Reusable Block" button appears only after a short delay (because it fetches user permission to create reusable block). I wonder that there may be a race condition similar to what we've seen previously with animations and the difference in time between when Puppeteer calculates a position and when it enacts a specific interaction (#13739). In this case, I wonder if it calculates the position of "Remove Block", then clicks, but in the time between those two steps the "Add to Reusable Blocks" button appears in the exact location the "Remove Block" button had been. This could explain the mismatch in the snapshot where, for no discernible reason, a reusable block exists in the content.
|
Lines 67 to 101 in 58da78c
|
Turns out it's my fault. At one point (#12378) this was preloaded (and thus there'd be no delay), but the preloading was removed in #13569, possibly because it had already landed in Core I don't consider it a blocker to merge this pull request. I can merge this one and then un-skip the test from #15061. |
…rnmobile/887-History-stack-is-not-empty-on-a-fresh-start-of-the-editor * 'master' of https://github.com/WordPress/gutenberg: Avoid running hasMetaBoxes on each subscribe (#15041) Avoid passing down isFirst and isLast props (#15043) Add "Roadmap" document with an overview of projects in consideration. (#14907) Testing: Update tests to use Escape press to activate block toolbar (#15063) Testing: Skip unreliable end-to-end tests (#15059)
Thanks for working on this one. I think it's extremely important to make e2e tests reliable as it seems to be a major issue for new contributors. It might scare them off when they discover those failures. We take too much for granted because we are on the project for so long. We know that those failures happen and have permissions to re-trigger builds. It shouldn't be the case. |
* Reusable Blocks: Preload user permissions * Testing: Unskip block deletion test See #15059 (comment)
This pull request seeks to disable unreliable end-to-end test cases until their reliability can be improved. They have been shown to cause intermittent build failures.
Testing Instructions:
Ensure end-to-end tests pass:
Follow-up Actions:
Create issue(s) for re-enabling skipped tests.