puppeteer/test/dialog.spec.ts

75 lines
2.2 KiB
TypeScript
Raw Normal View History

2018-11-21 04:18:57 +00:00
/**
* Copyright 2018 Google Inc. All rights reserved.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import expect from 'expect';
import sinon from 'sinon';
chore: fix async dialog specs when they fail (#5859) When this test was failing, it would cause no future tests to run. This was because the `expect` call within the `page.on` callback would throw an error, and that would trigger a unhandled promise rejection that caused the test framework to stop. The fundamental issue here is making `expect` calls within callbacks. They are brittle due to the fact that they throw, and the test framework won't catch it, but also because you have no guarantee that they will run. If the callback is never executed you dont' know about it. Although it's slightly more code, using a stub is the way to do this. Not only can we assert that the stub was called, we can make synchronous `expect` calls that Mocha will pick up properly if they fail. Before this change, running the tests (and making it fail on purpose) would cause all test execution to stop: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js .(node:69580) UnhandledPromiseRejectionWarning: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Page.<anonymous> (/Users/jacktfranklin/src/puppeteer/test/dialog.spec.js:42:37) [snip] (node:69580) UnhandledPromiseRejectionWarning: Unhandled promise rejection ... [snip] ``` But with this change, the rest of the tests run: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js Page.Events.Dialog ✓ should fire 1) should allow accepting prompts ✓ should dismiss the prompt 2 passing (2s) 1 failing 1) Page.Events.Dialog should allow accepting prompts: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Context.<anonymous> (test/dialog.spec.js:53:35) at processTicksAndRejections (internal/process/task_queues.js:94:5) ``` This is much better because one failing test now doesn't stop the rest of the test suite. This probably isn't the only instance of this in the codebase so I propose as we encounter them we fix them usng this commit as the template.
2020-05-14 09:34:22 +00:00
import {
2020-05-07 10:54:55 +00:00
getTestState,
setupTestPageAndContextHooks,
setupTestBrowserHooks,
itFailsFirefox,
} from './mocha-utils'; // eslint-disable-line import/extensions
2018-11-21 04:18:57 +00:00
2020-05-07 10:54:55 +00:00
describe('Page.Events.Dialog', function () {
setupTestBrowserHooks();
setupTestPageAndContextHooks();
2020-05-07 10:54:55 +00:00
it('should fire', async () => {
const { page } = getTestState();
2018-11-21 04:18:57 +00:00
const onDialog = sinon.stub().callsFake((dialog) => {
dialog.accept();
2018-11-21 04:18:57 +00:00
});
page.on('dialog', onDialog);
await page.evaluate(() => alert('yo'));
expect(onDialog.callCount).toEqual(1);
const dialog = onDialog.firstCall.args[0];
expect(dialog.type()).toBe('alert');
expect(dialog.defaultValue()).toBe('');
expect(dialog.message()).toBe('yo');
});
chore: fix async dialog specs when they fail (#5859) When this test was failing, it would cause no future tests to run. This was because the `expect` call within the `page.on` callback would throw an error, and that would trigger a unhandled promise rejection that caused the test framework to stop. The fundamental issue here is making `expect` calls within callbacks. They are brittle due to the fact that they throw, and the test framework won't catch it, but also because you have no guarantee that they will run. If the callback is never executed you dont' know about it. Although it's slightly more code, using a stub is the way to do this. Not only can we assert that the stub was called, we can make synchronous `expect` calls that Mocha will pick up properly if they fail. Before this change, running the tests (and making it fail on purpose) would cause all test execution to stop: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js .(node:69580) UnhandledPromiseRejectionWarning: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Page.<anonymous> (/Users/jacktfranklin/src/puppeteer/test/dialog.spec.js:42:37) [snip] (node:69580) UnhandledPromiseRejectionWarning: Unhandled promise rejection ... [snip] ``` But with this change, the rest of the tests run: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js Page.Events.Dialog ✓ should fire 1) should allow accepting prompts ✓ should dismiss the prompt 2 passing (2s) 1 failing 1) Page.Events.Dialog should allow accepting prompts: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Context.<anonymous> (test/dialog.spec.js:53:35) at processTicksAndRejections (internal/process/task_queues.js:94:5) ``` This is much better because one failing test now doesn't stop the rest of the test suite. This probably isn't the only instance of this in the codebase so I propose as we encounter them we fix them usng this commit as the template.
2020-05-14 09:34:22 +00:00
2020-05-07 10:54:55 +00:00
itFailsFirefox('should allow accepting prompts', async () => {
const { page } = getTestState();
chore: fix async dialog specs when they fail (#5859) When this test was failing, it would cause no future tests to run. This was because the `expect` call within the `page.on` callback would throw an error, and that would trigger a unhandled promise rejection that caused the test framework to stop. The fundamental issue here is making `expect` calls within callbacks. They are brittle due to the fact that they throw, and the test framework won't catch it, but also because you have no guarantee that they will run. If the callback is never executed you dont' know about it. Although it's slightly more code, using a stub is the way to do this. Not only can we assert that the stub was called, we can make synchronous `expect` calls that Mocha will pick up properly if they fail. Before this change, running the tests (and making it fail on purpose) would cause all test execution to stop: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js .(node:69580) UnhandledPromiseRejectionWarning: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Page.<anonymous> (/Users/jacktfranklin/src/puppeteer/test/dialog.spec.js:42:37) [snip] (node:69580) UnhandledPromiseRejectionWarning: Unhandled promise rejection ... [snip] ``` But with this change, the rest of the tests run: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js Page.Events.Dialog ✓ should fire 1) should allow accepting prompts ✓ should dismiss the prompt 2 passing (2s) 1 failing 1) Page.Events.Dialog should allow accepting prompts: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Context.<anonymous> (test/dialog.spec.js:53:35) at processTicksAndRejections (internal/process/task_queues.js:94:5) ``` This is much better because one failing test now doesn't stop the rest of the test suite. This probably isn't the only instance of this in the codebase so I propose as we encounter them we fix them usng this commit as the template.
2020-05-14 09:34:22 +00:00
const onDialog = sinon.stub().callsFake((dialog) => {
dialog.accept('answer!');
2018-11-21 04:18:57 +00:00
});
chore: fix async dialog specs when they fail (#5859) When this test was failing, it would cause no future tests to run. This was because the `expect` call within the `page.on` callback would throw an error, and that would trigger a unhandled promise rejection that caused the test framework to stop. The fundamental issue here is making `expect` calls within callbacks. They are brittle due to the fact that they throw, and the test framework won't catch it, but also because you have no guarantee that they will run. If the callback is never executed you dont' know about it. Although it's slightly more code, using a stub is the way to do this. Not only can we assert that the stub was called, we can make synchronous `expect` calls that Mocha will pick up properly if they fail. Before this change, running the tests (and making it fail on purpose) would cause all test execution to stop: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js .(node:69580) UnhandledPromiseRejectionWarning: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Page.<anonymous> (/Users/jacktfranklin/src/puppeteer/test/dialog.spec.js:42:37) [snip] (node:69580) UnhandledPromiseRejectionWarning: Unhandled promise rejection ... [snip] ``` But with this change, the rest of the tests run: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js Page.Events.Dialog ✓ should fire 1) should allow accepting prompts ✓ should dismiss the prompt 2 passing (2s) 1 failing 1) Page.Events.Dialog should allow accepting prompts: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Context.<anonymous> (test/dialog.spec.js:53:35) at processTicksAndRejections (internal/process/task_queues.js:94:5) ``` This is much better because one failing test now doesn't stop the rest of the test suite. This probably isn't the only instance of this in the codebase so I propose as we encounter them we fix them usng this commit as the template.
2020-05-14 09:34:22 +00:00
page.on('dialog', onDialog);
const result = await page.evaluate(() => prompt('question?', 'yes.'));
chore: fix async dialog specs when they fail (#5859) When this test was failing, it would cause no future tests to run. This was because the `expect` call within the `page.on` callback would throw an error, and that would trigger a unhandled promise rejection that caused the test framework to stop. The fundamental issue here is making `expect` calls within callbacks. They are brittle due to the fact that they throw, and the test framework won't catch it, but also because you have no guarantee that they will run. If the callback is never executed you dont' know about it. Although it's slightly more code, using a stub is the way to do this. Not only can we assert that the stub was called, we can make synchronous `expect` calls that Mocha will pick up properly if they fail. Before this change, running the tests (and making it fail on purpose) would cause all test execution to stop: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js .(node:69580) UnhandledPromiseRejectionWarning: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Page.<anonymous> (/Users/jacktfranklin/src/puppeteer/test/dialog.spec.js:42:37) [snip] (node:69580) UnhandledPromiseRejectionWarning: Unhandled promise rejection ... [snip] ``` But with this change, the rest of the tests run: ``` > puppeteer@3.0.4-post unit /Users/jacktfranklin/src/puppeteer > mocha --config mocha-config/puppeteer-unit-tests.js Page.Events.Dialog ✓ should fire 1) should allow accepting prompts ✓ should dismiss the prompt 2 passing (2s) 1 failing 1) Page.Events.Dialog should allow accepting prompts: Error: expect(received).toBe(expected) // Object.is equality Expected: "yes." Received: "" at Context.<anonymous> (test/dialog.spec.js:53:35) at processTicksAndRejections (internal/process/task_queues.js:94:5) ``` This is much better because one failing test now doesn't stop the rest of the test suite. This probably isn't the only instance of this in the codebase so I propose as we encounter them we fix them usng this commit as the template.
2020-05-14 09:34:22 +00:00
expect(onDialog.callCount).toEqual(1);
const dialog = onDialog.firstCall.args[0];
expect(dialog.type()).toBe('prompt');
expect(dialog.defaultValue()).toBe('yes.');
expect(dialog.message()).toBe('question?');
expect(result).toBe('answer!');
});
2020-05-07 10:54:55 +00:00
it('should dismiss the prompt', async () => {
const { page } = getTestState();
2020-05-07 10:54:55 +00:00
page.on('dialog', (dialog) => {
dialog.dismiss();
2018-11-21 04:18:57 +00:00
});
const result = await page.evaluate(() => prompt('question?'));
expect(result).toBe(null);
2018-11-21 04:18:57 +00:00
});
});