3e76554fcb
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. |
||
---|---|---|
.. | ||
assets | ||
fixtures | ||
golden-chromium | ||
golden-firefox | ||
accessibility.spec.js | ||
assert-coverage-test.js | ||
browser.spec.js | ||
browsercontext.spec.js | ||
CDPSession.spec.js | ||
chromiumonly.spec.js | ||
click.spec.js | ||
cookies.spec.js | ||
coverage-utils.js | ||
coverage.spec.js | ||
defaultbrowsercontext.spec.js | ||
dialog.spec.js | ||
diffstyle.css | ||
elementhandle.spec.js | ||
emulation.spec.js | ||
evaluation.spec.js | ||
fixtures.spec.js | ||
frame.spec.js | ||
golden-utils.js | ||
headful.spec.js | ||
ignorehttpserrors.spec.js | ||
input.spec.js | ||
jshandle.spec.js | ||
keyboard.spec.js | ||
launcher.spec.js | ||
mocha-utils.js | ||
mouse.spec.js | ||
navigation.spec.js | ||
network.spec.js | ||
oopif.spec.js | ||
page.spec.js | ||
queryselector.spec.js | ||
README.md | ||
requestinterception.spec.js | ||
run_static_server.js | ||
screenshot.spec.js | ||
target.spec.js | ||
touchscreen.spec.js | ||
tracing.spec.js | ||
utils.js | ||
waittask.spec.js | ||
worker.spec.js |
Puppeteer unit tests
Unit tests in Puppeteer are written using Mocha as the test runner and Expect as the assertions library.
Test state
We have some common setup that runs before each test and is defined in mocha-utils.js
.
You can use the getTestState
function to read state. It exposes the following that you can use in your tests. These will be reset/tidied between tests automatically for you:
puppeteer
: an instance of the Puppeteer library. This is exactly what you'd get if you ranrequire('puppeteer')
.puppeteerPath
: the path to the root source file for Puppeteer.defaultBrowserOptions
: the default options the Puppeteer browser is launched from in test mode, so tests can use them and override if required.server
: a dummy test server instance (seeutils/testserver
for more).httpsServer
: a dummy test server HTTPS instance (seeutils/testserver
for more).isFirefox
: true if running in Firefox.isChrome
: true if running Chromium.isHeadless
: true if the test is in headless mode.
If your test needs a browser instance, you can use the setupTestBrowserHooks()
function which will automatically configure a browser that will be cleaned between each test suite run. You access this via getTestState()
.
If your test needs a Puppeteer page and context, you can use the setupTestPageAndContextHooks()
function which will configure these. You can access page
and context
from getTestState()
once you have done this.
The best place to look is an existing test to see how they use the helpers.
Skipping tests for Firefox
Tests that are not expected to pass in Firefox can be skipped. You can skip an individual test by using itFailsFirefox
rather than it
. Similarly you can skip a describe block with describeFailsFirefox
.
There is also describeChromeOnly
which will only execute the test if running in Chromium. Note that this is different from describeFailsFirefox
: the goal is to get any FailsFirefox
calls passing in Firefox, whereas describeChromeOnly
should be used to test behaviour that will only ever apply in Chromium.
Running tests
Despite being named 'unit', these are integration tests, making sure public API methods and events work as expected.
- To run all tests:
npm run unit
- Important: don't forget to first run TypeScript if you're testing local changes:
npm run tsc && npm run unit
- To run a specific test, substitute the
it
withit.only
:
...
it.only('should work', async function() {
const {server, page} = getTestState();
const response = await page.goto(server.EMPTY_PAGE);
expect(response.ok).toBe(true);
});
- To disable a specific test, substitute the
it
withxit
(mnemonic rule: 'cross it'):
...
// Using "xit" to skip specific test
xit('should work', async function({server, page}) {
const {server, page} = getTestState();
const response = await page.goto(server.EMPTY_PAGE);
expect(response.ok).toBe(true);
});
- To run tests in non-headless mode:
HEADLESS=false npm run unit
- To run tests with custom browser executable:
BINARY=<path-to-executable> npm run unit