mirror of https://github.com/zhigang1992/create-react-app.git synced 2026-04-01 09:01:04 +08:00

Files

Clement Hoang 1552949a3b Switch to Babel 7 (#3522 )

* Update dependencies in react-scripts

* Add first pass of working dependencies for babel-preset-react-app and react-scripts

* Bump more dependency versions

* Adjust more versions and edit fix options

* Restore functionality of old preset

* Disable Uglify in iframe webpack

* Apply prettier

* Re-enable cache in dev and clean deps

* Lock packages and move babel/core to dep in preset

* Bump babel-jest

* Re-enable uglify

* Nest forceAllTransforms correctly in webpack config

* Install babel-core bridge for jest

* Add jest-cli and babel-core bridge to make tests in react-error-overlay pass

* Re-enable transform-dynamic-import

* Add dynamic import syntax support back

* Use new babel in kitchensink

* Transform modules in test

* Revert "Transform modules in test"

This reverts commit 539e46a1d77259898b7e70d778a5e43fc25edc2a.

* Attempt fix for ejected tests

* try this

* Add regenerator back

* Bump babel deps to beta.34

* Remove bad files

* Use default when requiring babel transform plugin

* Bump deps

* Try the fix?

* Oopsie

* Remove some weird things

* Run Babel on react-error-overlay tests

* Try fixing kitchensink

* Use new API for codeFrame

* Add missing (?) babelrc

* Maybe this helps?

* Maybe fix mocha

* I shouldn't have deleted this 🤦

2018-01-15 00:07:57 -05:00

integration

fix #2223 - [feature] Implement dotenv-expand to accept variable expa… (#3387 )

2018-01-09 16:05:36 +00:00

public

Use a more sophisticated template for end-to-end testing. (#1187 )

2017-01-23 20:43:16 +01:00

src

Always include destructuring transform (#3788 )

2018-01-14 15:37:00 +00:00

.env

fix #2223 - [feature] Implement dotenv-expand to accept variable expa… (#3387 )

2018-01-09 16:05:36 +00:00

.env.development

Feature/different env config files #1343 (#1344 )

2017-05-12 11:30:59 +01:00

.env.local

Feature/different env config files #1343 (#1344 )

2017-05-12 11:30:59 +01:00

.env.production

Feature/different env config files #1343 (#1344 )

2017-05-12 11:30:59 +01:00

.flowconfig

Use a more sophisticated template for end-to-end testing. (#1187 )

2017-01-23 20:43:16 +01:00

.template.dependencies.json

Switch to Babel 7 (#3522 )

2018-01-15 00:07:57 -05:00

gitignore

Use a more sophisticated template for end-to-end testing. (#1187 )

2017-01-23 20:43:16 +01:00

README.md

Local testing docker links (#2662 )

2017-06-28 16:01:08 +01:00

README.md

Contributing to Create React App's E2E tests

This is an end to end kitchensink test suite, but has multiple usages in it.

Running the test suite

Tests are automatically run by the CI tools.
In order to run them locally, without having to manually install and configure everything, the yarn e2e:docker CLI command can be used.

This is a simple script that runs a Docker container, where the node version, git branch to clone, test suite, and whether to run it with yarn or npm can be chosen.
Simply run yarn e2e:docker -- --help to get additional info.

If you need guidance installing Docker, you should follow their official docs.

Writing tests

Each time a new feature is added, it is advised to add at least one test covering it.

Features are categorized by their scope:

env, all those which deal with environment variables (e.g. NODE_PATH)
syntax, all those which showcase a single EcmaScript syntax feature that is expected to be transpiled by Babel
webpack, all those which make use of webpack settings, loaders or plugins

Using it as Unit Tests

In it's most basic for this serve as a collection of unit tests on a single functionality.

Unit tests are written in a src/features/**/*.test.js file located in the same folder as the feature they test, and usually consist of a simple ReactDOM.render call.

These tests are run by jest and the environment is test, so that it resembles how a Create React App application is tested.

Using it as Integration Tests

This suite tests how the single features as before behave while development and in production.
A local HTTP server is started, then every single feature is loaded, one by one, to be tested.

Test are written in integration/{env|syntax|webpack}.test.js, depending on their scope.

For every test case added there is just a little chore to do:

a case statement must be added in src/App.js, which simply perform a dynamic import() of the feature
add a test case in the appropriate integration test file, which calls and awaits initDOM with the previous SwitchCase string

An usual flow for the test itself is something similar to:

add an id attribute in a target HTML tag in the feature itself
since initDOM returns a Document element, the previous id attribute is used to target the feature's DOM and expect accordingly

These tests are run by mocha (why not jest? See this issue) and the environments used are both development and production.