Reset embed mocks on every request, stop request to instagram

[notnownikki]

Description

After the retry test, mocks were not reset and so actual network requests happened. This made the tests unreliable, so this PR makes sure the mocks are reset for every test, and the instagram request is also mocked.

Types of changes

Bug fix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

Should we remove the other matcher?

gutenberg/packages/e2e-tests/specs/embedding.test.js

Lines 105 to 106 in 82a5ecc

	match: createEmbeddingMatcher( 'https://www.instagram.com/p/Bvl97o2AK6x/' ),
	onRequestMatch: createJSONResponse( MOCK_EMBED_IMAGE_SUCCESS_RESPONSE ),

[gziolo]

it doesn't seem to be used at the moment

[notnownikki]

No, one is to match the embed preview request for the URL and one is to match the URL itself. The image block creates a new image, and sets the URL as the source. If the image errors, it replaces itself with an appropriate embed block if there is one. So we need to mock the instagram URL, and the embed proxy call that generates the preview.

[gziolo]

Awesome, it makes sense now :)

[gziolo]

Many thanks for working on this fix. Let's get this in and see if it resolves the issue I have in #15018 :)

[aduth]

I'm not positive that it's related to the changes here, though it appears relevant: In #15049 I've encountered an intermittent test failure from the embedding.test.js suite:

FAIL packages/e2e-tests/specs/embedding.test.js (65.496s)
  ● Embedding content › should transform from audio to embed block when Soundcloud URL is pasted
    waiting for selector ".wp-block-embed-soundcloud" failed: timeout 30000ms exceeded
      299 | 		await page.keyboard.type( 'https://soundcloud.com/a-boogie-wit-da-hoodie/swervin' );
      300 | 		await page.keyboard.press( 'Enter' );
    > 301 | 		await page.waitForSelector( '.wp-block-embed-soundcloud' );
          | 		           ^
      302 | 	} );
      303 | } );
      304 | 
      at new WaitTask (../../node_modules/puppeteer/lib/FrameManager.js:840:28)
      at Frame._waitForSelectorOrXPath (../../node_modules/puppeteer/lib/FrameManager.js:731:12)
      at Frame.waitForSelector (../../node_modules/puppeteer/lib/FrameManager.js:690:17)
      at Page.waitForSelector (../../node_modules/puppeteer/lib/Page.js:1008:29)
      at Object.waitForSelector (specs/embedding.test.js:301:14)
      at tryCatch (../../node_modules/regenerator-runtime/runtime.js:62:40)
      at Generator.invoke [as _invoke] (../../node_modules/regenerator-runtime/runtime.js:288:22)
      at Generator.prototype.(anonymous function) [as next] (../../node_modules/regenerator-runtime/runtime.js:114:21)
      at asyncGeneratorStep (specs/embedding.test.js:9:103)
      at _next (specs/embedding.test.js:11:194)

https://travis-ci.com/WordPress/gutenberg/jobs/194055234

[youknowriad]

Got the same error in another PR @aduth I think we should start disabling all intermittent failures and create issues about these tests.

[notnownikki]

Yes, the timeout failures aren't caused by the changes here, they're uncovered by the changes here. Previously the tests were failing most of the time with console errors due to the mocks not being applied.

I've seen these happen once running the tests locally, I'm not sure what causes it, but the end result is that the blocks aren't getting replaced with embed blocks when they should be. The failure I saw locally was the video block turned into a video player, trying to play a youtube URL.

I agree with disabling the tests, and I can see if I can track down what's causing it, although I doubt it's related to the embed blocks, as the problem is we don't get on to the stage where the embed blocks appear.

[aduth]

Got the same error in another PR @aduth I think we should start disabling all intermittent failures and create issues about these tests.

See #15059