Skip to content

test(e2e): improve puppeteer argument flags #2127

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

Merged
merged 18 commits into from
Jul 23, 2019

Conversation

knagaitsev
Copy link
Collaborator

  • This is a bugfix
  • This is a feature
  • This is a code refactor
  • This is a test update
  • This is a docs update
  • This is a metadata update

For Bugs and Features; did you add new tests?

N/A

Motivation / Use-Case

Use the recommended args for puppeteer from https://github.com/alixaxel/chrome-aws-lambda/blob/master/source/index.js

Hopefully this could make e2e tests more stable.

Breaking Changes

None

Additional Info

@codecov
Copy link

codecov bot commented Jul 16, 2019

Codecov Report

Merging #2127 into master will decrease coverage by 0.13%.
The diff coverage is 50%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2127      +/-   ##
==========================================
- Coverage   92.67%   92.53%   -0.14%     
==========================================
  Files          32       32              
  Lines        1256     1260       +4     
  Branches      360      360              
==========================================
+ Hits         1164     1166       +2     
- Misses         85       87       +2     
  Partials        7        7
Impacted Files Coverage Δ
lib/servers/SockJSServer.js 93.75% <50%> (-2.92%) ⬇️
lib/servers/WebsocketServer.js 89.47% <50%> (-4.65%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 75718b7...7f6712f. Read the comment docs.

@hiroppy
Copy link
Member

hiroppy commented Jul 17, 2019

fmm.. CI fails. 😞 sometimes CI is stopped by Azure because of timeout.

@alexander-akait
Copy link
Member

@Loonride maybe we can add timeout for puppeteer to avoid 60 minutes

@knagaitsev
Copy link
Collaborator Author

/cc @evilebottnawi @hiroppy Got it working! Turns out it was some timing issues.

@hiroppy
Copy link
Member

hiroppy commented Jul 18, 2019

👍 This test seems to be a flaky test.

FAIL test/e2e/Progress.test.js (12.03s)
  ● client progress › using hot › on browser client › should console.log progress

    Error [ERR_UNHANDLED_ERROR]: Unhandled error. (Error: Page crashed!

      at Page._onTargetCrashed (node_modules/puppeteer/lib/Page.js:230:24)
      at CDPSession.Page.client.on.event (node_modules/puppeteer/lib/Page.js:175:56)
      at CDPSession._onMessage (node_modules/puppeteer/lib/Connection.js:252:12)
      at Connection._onMessage (node_modules/puppeteer/lib/Connection.js:143:28)
      at WebSocketTransport._ws.addEventListener.event (node_modules/puppeteer/lib/WebSocketTransport.js:47:42)
      at WebSocket.onMessage (node_modules/ws/lib/event-target.js:127:16)
      at Receiver.receiverOnMessage (node_modules/ws/lib/websocket.js:746:20)
      at Receiver.dataMessage (node_modules/ws/lib/receiver.js:428:14)
      at Receiver.getData (node_modules/ws/lib/receiver.js:360:17)
      at Receiver.startLoop (node_modules/ws/lib/receiver.js:152:22)
      at Receiver._write (node_modules/ws/lib/receiver.js:83:10)
      at Socket.socketOnData (node_modules/ws/lib/websocket.js:819:35)
      at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17))
      at Page._onTargetCrashed (node_modules/puppeteer/lib/Page.js:230:10)
      at CDPSession.Page.client.on.event (node_modules/puppeteer/lib/Page.js:175:56)
      at CDPSession._onMessage (node_modules/puppeteer/lib/Connection.js:252:12)
      at Connection._onMessage (node_modules/puppeteer/lib/Connection.js:143:28)
      at WebSocketTransport._ws.addEventListener.event (node_modules/puppeteer/lib/WebSocketTransport.js:47:42)
      at WebSocket.onMessage (node_modules/ws/lib/event-target.js:127:16)
      at Receiver.receiverOnMessage (node_modules/ws/lib/websocket.js:746:20)

@knagaitsev
Copy link
Collaborator Author

/cc @evilebottnawi @hiroppy Still possibly not perfect, but appears more reliable. Here are my changes:

  • use testSequencer.js to space out tests such that e2e tests are evenly spread out. I suspect that running many e2e tests concurrently can lead to problems
  • added more timing wait events - this will increase test time a bit but I think it is worth it
  • use done() callback instead of returning a Promise in e2e tests. Not sure if this makes any difference, but the e2e tests that returned promises were being flaky.
  • Always do expect(...) testing right before the done() call. I saw strange behavior once before when there was a delay between expect testing and the final callback.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job, some notes

// prevent cases where the server is trying to send data while connection is closing
if (connection.readyState === 1) {
connection.write(message);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, let's rewrite

if (connection.readyState !== 1) {
  return;
}

connection.write(message);

Hope it is not break code 😄

// prevent cases where the server is trying to send data while connection is closing
if (connection.readyState === 1) {
connection.send(message);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look above

@@ -54,17 +54,29 @@ describe('clientMode', () => {
res.push(_text);
});

setTimeout(() => {
page.waitFor(3000).then(() => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Magic number, let's create file test/server/helpers/server-constans.js and move this values in variable with name

@@ -31,5 +31,6 @@ Array [
exports[`Client console.log liveReload enabled 1`] = `
Array [
"Hey.",
"[WDS] Live Reloading enabled.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it is appears here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@evilebottnawi Previously, inline was disabled for this test, so the live reload message was not printed. Look at the change in test-server.js. I made it so that options.inline is not set automatically to false when options.liveReload exists. This test makes more sense if inline is enabled.

'--prerender-from-omnibox=disabled',
'--use-gl=swiftshader',
'--use-mock-keychain',
],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's move this in variable and put above in file or maybe in other file

}
}

module.exports = CustomSequencer;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add docs in above function and describe what it is do and why we need this, it can be misleading for other developers without description

@knagaitsev
Copy link
Collaborator Author

@evilebottnawi Should I add a test for the readyState !== 1 feature?

@@ -0,0 +1,52 @@
'use strict';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's name file puppeteer-constaints.js

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One note, good work!

@knagaitsev
Copy link
Collaborator Author

Oddly on the Windows node-8 test failure, the tests did not run in the specified order

@alexander-akait
Copy link
Member

@Loonride maybe something wrong with paths?

@knagaitsev
Copy link
Collaborator Author

knagaitsev commented Jul 19, 2019

It looks like ordering isn't working on Windows CI, probably because of path yes, I will investigate

Edit: Yes, Windows test paths using backslash

@alexander-akait alexander-akait merged commit 05bdb0c into webpack:master Jul 23, 2019
knagaitsev added a commit to knagaitsev/webpack-dev-server that referenced this pull request Jul 31, 2019
@knagaitsev knagaitsev added gsoc Google Summer of Code type: test labels Aug 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gsoc Google Summer of Code type: test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants