Skip to content

Commit

Permalink
Try: Testing: Experiment with Puppeteer for E2E testing (#5618)
Browse files Browse the repository at this point in the history
* Testing: Try puppeteer for E2E testing

* E2E tests: move the hello gutenberg cypress test

* E2E tests: Adding blocks test moved to puppeteer

* Add multi-selection test

* Adding the managing links test

* Replace cypress with jest puppeteer

* Remove useless eslint configs

* Removing useless comments

* Using snapshots for adding blocks tests

* update Puppeteer to 1.2.0

* Increase Jest Timeout for slow CI environments

* More stable tests by increasing timeouts and launching a new page on each test

* Try treating the timeout as a successful navigation

* Tools: Use Eslint overrides for e2e tests

* Tools: Use Eslint overrides for e2e tests

* Adding dependencies comment
  • Loading branch information
aduth authored and youknowriad committed Mar 23, 2018
1 parent 223342a commit 4eed1e4
Show file tree
Hide file tree
Showing 27 changed files with 506 additions and 1,041 deletions.
1 change: 0 additions & 1 deletion .eslintignore
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
build
coverage
cypress
node_modules
vendor
9 changes: 9 additions & 0 deletions .eslintrc.js
Original file line number Diff line number Diff line change
Expand Up @@ -92,4 +92,13 @@ module.exports = {
},
],
},
overrides: [
{
files: [ 'test/e2e/**/*.js' ],
globals: {
page: true,
browser: true,
},
},
],
};
2 changes: 0 additions & 2 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
# Directories/files that may be generated by this project
build
coverage
cypress
/hooks
node_modules
gutenberg.zip
Expand All @@ -14,4 +13,3 @@ languages/gutenberg.pot
phpcs.xml
yarn.lock
docker-compose.override.yml
cypress.env.json
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ The workflow is documented in greater detail in the [repository management](./do

## Testing

Gutenberg contains both PHP and JavaScript code, and encourages testing and code style linting for both. It also incorporates end-to-end testing using [Cypress](https://www.cypress.io/). You can find out more details in [Testing Overview document](./docs/testing-overview.md).
Gutenberg contains both PHP and JavaScript code, and encourages testing and code style linting for both. It also incorporates end-to-end testing using [Google Puppeteer](https://developers.google.com/web/tools/puppeteer/). You can find out more details in [Testing Overview document](./docs/testing-overview.md).

## How Designers Can Contribute

Expand Down
12 changes: 0 additions & 12 deletions cypress.json

This file was deleted.

20 changes: 7 additions & 13 deletions docs/testing-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ Gutenberg contains both PHP and JavaScript code, and encourages testing and code

## Why test?

Aside from the joy testing will bring to your life, tests are important not only because they help to ensure that our application behaves as it should, but also because they provide concise examples of how to use a piece of code.
Aside from the joy testing will bring to your life, tests are important not only because they help to ensure that our application behaves as it should, but also because they provide concise examples of how to use a piece of code.

Tests are also part of our code base, which means we apply to them the same standards we apply to all our application code.
Tests are also part of our code base, which means we apply to them the same standards we apply to all our application code.

As with all code, tests have to be maintained. Writing tests for the sake of having a test isn't the goal – rather we should try to strike the right balance between covering expected and unexpected behaviours, speedy execution and code maintenance.

Expand Down Expand Up @@ -44,7 +44,7 @@ Keep your tests in a `test` folder in your working directory. The test file shou
Only test files (with at least one test case) should live directly under `/test`. If you need to add external mocks or fixtures, place them in a sub folder, for example:

* `test/mocks/[file-name.js`
* `test/fixtures/[file-name].js`
* `test/fixtures/[file-name].js`

### Importing tests

Expand Down Expand Up @@ -90,7 +90,7 @@ describe( 'CheckboxWithLabel', () => {

The Jest API includes some nifty [setup and teardown methods](https://facebook.github.io/jest/docs/en/setup-teardown.html) that allow you to perform tasks *before* and *after* each or all of your tests, or tests within a specific `describe` block.

These methods can handle asynchronous code to allow setup that you normally cannot do inline. As with [individual test cases](https://facebook.github.io/jest/docs/en/asynchronous.html#promises), you can return a Promise and Jest will wait for it to resolve:
These methods can handle asynchronous code to allow setup that you normally cannot do inline. As with [individual test cases](https://facebook.github.io/jest/docs/en/asynchronous.html#promises), you can return a Promise and Jest will wait for it to resolve:

```javascript
// one-time setup for *all* tests
Expand All @@ -105,7 +105,7 @@ afterAll( () => {
```

`afterEach` and `afterAll` provide a perfect (and preferred) way to 'clean up' after our tests, for example, by resetting state data.

Avoid placing clean up code after assertions since, if any of those tests fail, the clean up won't take place and may cause failures in unrelated tests.

### Mocking dependencies
Expand Down Expand Up @@ -152,9 +152,9 @@ Because we're passing the list as an argument, we can pass mock `validValuesLis

#### Imported dependencies

Often our code will use methods and properties from imported external and internal libraries in multiple places, which makes passing around arguments messy and impracticable. For these cases `jest.mock` offers a neat way to stub these dependencies.
Often our code will use methods and properties from imported external and internal libraries in multiple places, which makes passing around arguments messy and impracticable. For these cases `jest.mock` offers a neat way to stub these dependencies.

For instance, lets assume we have `config` module to control a great deal of functionality via feature flags.
For instance, lets assume we have `config` module to control a great deal of functionality via feature flags.

```javascript
// bilbo.js
Expand Down Expand Up @@ -361,12 +361,6 @@ or interactively
npm run test-e2e:watch
```

If you're using another local environment setup, you can still run the e2e tests by overriding the base URL and the default WP username/password used in the tests like so:

```bash
cypress_base_url=http://my-custom-basee-url cypress_username=myusername cypress_password=mypassword npm run test-e2e
```

## PHP Testing

Tests for PHP use [PHPUnit](https://phpunit.de/) as the testing framework. If you're using the built-in [local environment](https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md#local-environment), you can run the PHP tests locally using this command:
Expand Down
Loading

0 comments on commit 4eed1e4

Please sign in to comment.