huddleeng / muppeteer Goto Github PK

It should be possible to add Docker support internally rather than the end user having to configure it all. The only dependency would be Docker being installed, which we can do dependency detection for.

Things to do:

• Add config option so that someone can run tests in docker, default to latest stable release of Chrome, but perhaps allow tagging of a particular version too
• Add dependency detection for Docker, and tell user to download it if not available
  -- CI, like Travis, will have a docker option
• Make sure an Dockerfile for Chrome dependencies exists
• Set up volume mount mapping to the visual path/report path for Docker container
• Make sure cleanup of container/images exist
• ...
• Probs some other stuff I forgotten

The example tests currently run on the live TodoMVC website. If that goes down or changes, the tests will break. A local server should be used in the tests with a copy of the example code base.

Using latest tag for Docker Hub builds is not ideal because it's non deterministic, and breakages in Chrome could cause visuals failures out of the blue without the user knowing why.

• Use chrome-headless-stable instead of chrome-headless-trunk because we don't want to keep releasing for every minor change - particularly unstable changes.
• Pin the version in the docker-compose.yml file
• Create a script to pull latest tags from Docker hub and update the docker-compose.yml file if there's a new tag. The script publish a PR for this.
• Add an automated way to do this - for example, a daily job running on a server
• Consider the approach to releasing a new version. PR could be automatically merged and a release published, but stuff on master would end up in it too without me knowing.

There are currently no tests for the framework. They are needed to check for regressions and encourage TDD.

test-launcher should be in lib, move misc API functions into separate files.

The current HTML report shows the diff image when a test fails but it would be useful in a dev environment to see all visual baselines and any diffs that were generated after tests run locally. We could then have an option to interactivity rebase visuals.

To achieve this, we need a task to launch a Node server (like Express) via a new CLI option and an associated JS function returned from ConfigureLauncher

TodoMVC has some animations, so the test occasionally fail in an intermediate animation state. Need to run turnOffAnimations extension function before running the tests.

Issue:

When awaiting waitForLoadedWebFontCountToBe, the function times out even though a successful response has occurred.

Resolution
r.resourceType is not getter, it's a function, which needs to be invoked. We also should check the response code for success (200 OK or 304 Not Modified). Redirects would lead to a second request, where the response would be one of the above.

There is an advisory for the npm package puppeteer that can be solved by upgrading to a later version than v1.13.0. Muppeteer v1.3.0 currently uses puppeteer v1.2.0.

Please see below for detail on the issue:
https://nodesecurity.io/advisories/824

It appears that the below commit addresses the puppeteer dependency, but there is no corresponding release:
2c373c9

Would you consider a release addressing the above? Thank you.

The CLI should accept all possible configurations other than the following, which must be provided as handlers to the configuration function internally:

• componentTestUrlFactory
• componentTestVisualPathFactory
• onFinish

shouldRebaseVisuals is the only option missing currently.

to the tests to run I had to go into "/cromium/Dockerfile" line 1, and change

"FROM alpeware/chrome-headless-trunk:rev-599821"

to

"FROM alpeware/chrome-headless-trunk"

and in "src/utils/dockerChrome.js" comment out lines 125-128

// const data = readFileSync(dockerFilePath, { encoding: 'utf-8' });
// const previousTag = data.match(/:(.*)/)[1]; // get everything after : on same line
// const newData = data.replace(previousTag, latestTag);
// writeFileSync(dockerFilePath, newData, { encoding: 'utf-8' });

Originally I tried to use Jest for the runner but had problems getting a custom interface to work. This was quite some time ago, and Mocha was dead simple to use. Jest may have improved this area since then, so it's worth trying again.

The waitForResource function is erroring on the URL check in the latest version of Puppeteer.

Problems with bad config or timeouts can lead to broken promises, and it's often difficult to determine the cause. More error handling is needed closer to the source to either resolve issues or throw useful messages up the stack.

Firstly, thanks for creating this project. 👍

I am trying to run a very basic test with muppeteer using CLI but getting below error. Can you please help me resolve it? Let me know if I am doing something wrong.
TypeError: ConfigureLauncher(...).launch is not a function

Attached is a screenshot.

The Muppeteer API exposes the page and assert modules onto the Muppeteer object, which is available in the context of the test interface. The two modules can just be put directly on the context to avoid the end user having to type Muppeteer.* all the time.

An alternative press function was created a while back to work with the legacy keypress handler. It seems newer versions of Puppeteer have solved this so the naughtyPress function can go away.

In preparation for allowing community to contribute to the project, we need the necessary documentation, such as a contributing file and a code of conduct, plus anything else I can think of.

I want to make muppeteer run **/*.js files, but now I can't because:

It seems that if you have configured the option testFilter: '.js' it only runs 'test.js' file.

I don't understand why it is designed in this way, is there anyway to run **/*.js files?