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

Don't use expect within Promises (#5466) #5473

Merged
merged 2 commits into from May 26, 2020

Conversation

whimboo
Copy link
Collaborator

@whimboo whimboo commented Mar 4, 2020

This PR will partly fix issue #5466.

If a call to expect fails within a Promise it will not
be resolved, and causing the test to crash.

The patch aligns the code similar to what is used by all
the other tests.

@whimboo whimboo force-pushed the expect_in_callback branch 2 times, most recently from 28da0f6 to 2a17630 Compare March 4, 2020 12:41
@whimboo
Copy link
Collaborator Author

whimboo commented Mar 4, 2020

@mathiasbynens, in regards of the Travis and AppVeyor failure for navitation.spec.js shouldn't await page.goto() wait until all the requests have been processed?

let error = null;
await page.goto(httpsServer.EMPTY_PAGE).catch(e => error = e);
if (CHROME)
expect(error.message).toContain('net::ERR_CERT_AUTHORITY_INVALID');
else
expect(error.message).toContain('SSL_ERROR_UNKNOWN');
expect(requests.length).toBe(3);
for (const request of requests)
expect(request).toBeTruthy();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@mathiasbynens this change actually caused tests to fail for Chrome:
https://travis-ci.com/github/puppeteer/puppeteer/jobs/293846770#L543

Any suggestion what has to be done to get this fixed? Maybe waiting until the length is 3?

@jackfranklin
Copy link
Collaborator

Hey @whimboo I'm afraid we've got some conflicts now we've done some updates to the test runner (we now use Mocha rather than a custom one). Would you be up for rebasing and landing this work? I'm happy to work with you to figure out that navigation.spec.js test if it's still causing issues after a rebase.

@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

Hey @jackfranklin. Sorry for not replying earlier but I missed the Github notification. I will have a look in updating this PR (in case the changes are still needed). Maybe I will have something later today.

@jackfranklin
Copy link
Collaborator

@whimboo no probs! Ping me if I can help :)

@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

I hope the recently pushed changes will work. I'm currently not able to test locally because of the following failure message:

Error: Cannot find module './lib/helper'
Require stack:
- /Users/henrik/code/puppeteer/index.js
- /Users/henrik/code/puppeteer/test/mocha-utils.js
- /Users/henrik/code/puppeteer/node_modules/mocha/lib/mocha.js
- /Users/henrik/code/puppeteer/node_modules/mocha/lib/cli/one-and-dones.js
- /Users/henrik/code/puppeteer/node_modules/mocha/lib/cli/options.js
- /Users/henrik/code/puppeteer/node_modules/mocha/bin/mocha

And there is not such a lib folder.

@jackfranklin
Copy link
Collaborator

jackfranklin commented May 12, 2020

@whimboo can you run node install.js or npm run tsc?

@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

Oh node install.js worked. Can we get this step added to https://github.com/puppeteer/puppeteer/blob/master/test/README.md?

@jackfranklin
Copy link
Collaborator

@whimboo #5852 should clarify the testing part

@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

@jackfranklin the problem with the navigation test failure still exists:
https://travis-ci.com/github/puppeteer/puppeteer/jobs/332575437#L289-L297

@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

I assume this is a bug in the test and that we should not expect requestfinished to be fired, but only requestfailed. Modifying the test I see the following events being emitted:

*** request
*** requestfailed

@whimboo whimboo force-pushed the expect_in_callback branch 2 times, most recently from 0e917d5 to 13b0545 Compare May 12, 2020 19:18
@whimboo
Copy link
Collaborator Author

whimboo commented May 12, 2020

@jackfranklin if those checks are fine, all the tests passing now.

const requests = [];
page.on('request', (request) => requests.push('request'));
page.on('requestfinished', (request) => requests.push('requestfinished'));
page.on('requestfailed', (request) => requests.push('requestfailed'));
Copy link
Collaborator

Choose a reason for hiding this comment

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

@whimboo to check my understanding; do you think this test used to pass because we've never get a requestfinished event and therefore that expectation would never run?

@mathiasbynens do you have any thoughts on if we should be getting the requestfinished event? I think it makes sense that we don't, given that this test checks that requests fail and therefore I wouldn't expect the requestfinished event necessarily. I think this was a mistake in the test that made it in and happened to not cause any issues.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, exactly. I think we either get requestfinished or requestfailed. But agreed that this is something @mathiasbynens should reply on.

@whimboo
Copy link
Collaborator Author

whimboo commented May 13, 2020

@jackfranklin also I assume half of the changes for this PR are super-seeded by your PR #5859?

@jackfranklin
Copy link
Collaborator

@whimboo ah yes looks like it might be - sorry to cause more work for you :( Let's get #5859 and then rebase this PR. Apologies for the back and forth.

@whimboo
Copy link
Collaborator Author

whimboo commented May 14, 2020

No problem at all. Are the changes to the navigation tests ok, or would they have to be updated similar to your dialog changes?

@jackfranklin
Copy link
Collaborator

@whimboo apologies, this slipped off my radar. I just tried to rebase on GitHub but I've made a mistake and now the tests are failing. If you could tidy up the failing test on your fork and push then this will be good to merge. Thanks!

@@ -54,6 +57,9 @@ describe('Page.Events.Dialog', function () {
expect(dialog.message()).toBe('question?');

expect(result).toBe('answer!');
expect(type).toBe('prompt');
expect(defaultValue).toBe('yes.');
expect(message).toBe('question?');
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@jackfranklin do we still need those changes or are all of these obsolete now? Also what about the other test above. I assume it needs a similar call to sinon.stub().callsFake()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I just pushed an update with that. So let me know if that is fine with you.

If a call to expect fails within a Promise it will not
be resolved, and causing the test to crash.

The patch aligns the code similar to what is used by all
the other tests.
@whimboo
Copy link
Collaborator Author

whimboo commented May 25, 2020

Tests are failing because of Error: src/protocol.d.ts is out of date.. I pushed another update.

@jackfranklin jackfranklin merged commit 6cfe142 into puppeteer:master May 26, 2020
@jackfranklin
Copy link
Collaborator

@whimboo thanks! Sorry again for the back and forth on this one.

@whimboo whimboo deleted the expect_in_callback branch May 26, 2020 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants