E2E Tests: Mock Embed response for InnerBlocks locking test #20481
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
aduth
added
[Type] Automated Testing
aduth
requested review from
ajitbohra,
nerrad,
ntwb and
talldan
as code owners
|
Size Change: 0 B Total Size: 864 kB ℹ️ View Unchanged
|
|
Interestingly, the build is currently failing with the exact intermittent issue this was intended to address: https://travis-ci.com/WordPress/gutenberg/jobs/291457268 I'll need to spend more time investigating this. |
aduth
force-pushed
the
fix/e2e-test-innerblocks-embed
branch
from
266b4f6 to
4bf28a6
Compare
aduth
force-pushed
the
fix/e2e-test-innerblocks-embed
branch
from
4bf28a6 to
fff865f
Compare
|
Request interception seems to be working as expected, both locally and in Travis. I created a test commit 4bf28a6c5f0d6c8a0ee5dc5b54f52cb643a5344d to verify this, which output as expected: The errors seen previously "Error: sandbox not initialized" is most definitely caused by something related with Twitter. You can Ctrl-F search the thrown error with message "sandbox not initialized" in https://platform.twitter.com/widgets.js The interception introduced here should be preventing this file from being loaded, and evidenced by the logging above, it does, at least sometimes. I tried debugging some of the machinery of our request mocking to see where things could possibly go wrong, and while I was able to make some general improvements (#20811), I don't believe these to be a cause of failure, since the Travis site is set up in a way we expect it to be with permalinks. |
|
In any case, this test needs mocking. We don't want real network requests to third-parties, because those can be unreliable and cause false failures. It at least appears to be working sometimes, or at least as effectively as the existing embedding tests and their mocking upon which it's based. |
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.
This pull request seeks to improve end-to-end test stability for the
editor/plugins/innerblocks-locking-all-embed.jstests. These test cases have been observed to fail intermittently.Example: https://travis-ci.com/WordPress/gutenberg/jobs/291310078
It is suspected that these are caused by unreliability of third-party network requests. This has been a problem in the past for other tests which include embeds, which led to the implementation of mocking for the core embedding tests (#10467, #11250).
Testing Instructions:
Verify that the affected tests still pass: