|
| 1 | +# Contributing to Create React App's E2E tests |
| 2 | + |
| 3 | +This is an end to end kitchensink test suite, but has multiple usages in it. |
| 4 | + |
| 5 | +## Running the test suite |
| 6 | + |
| 7 | +Tests are automatically run by the CI tools. |
| 8 | +In order to run them locally, without having to manually install and configure everything, the `yarn e2e:docker` CLI command can be used. |
| 9 | + |
| 10 | +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. |
| 11 | +Simply run `yarn e2e:docker -- --help` to get additional info. |
| 12 | + |
| 13 | +## Writing tests |
| 14 | + |
| 15 | +Each time a new feature is added, it is advised to add at least one test covering it. |
| 16 | + |
| 17 | +Features are categorized by their scope: |
| 18 | + |
| 19 | + - *env*, all those which deal with environment variables (e.g. `NODE_PATH`) |
| 20 | + |
| 21 | + - *syntax*, all those which showcase a single EcmaScript syntax feature that is expected to be transpiled by **Babel** |
| 22 | + |
| 23 | + - *webpack*, all those which make use of webpack settings, loaders or plugins |
| 24 | + |
| 25 | +### Using it as Unit Tests |
| 26 | + |
| 27 | +In it's most basic for this serve as a collection of unit tests on a single functionality. |
| 28 | + |
| 29 | +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. |
| 30 | + |
| 31 | +These tests are run by **jest** and the environment is `test`, so that it resembles how a **Create React App** application is tested. |
| 32 | + |
| 33 | +### Using it as Integration Tests |
| 34 | + |
| 35 | +This suite tests how the single features as before behave while development and in production. |
| 36 | +A local HTTP server is started, then every single feature is loaded, one by one, to be tested. |
| 37 | + |
| 38 | +Test are written in `integration/{env|syntax|webpack}.test.js`, depending on their scope. |
| 39 | + |
| 40 | +For every test case added there is just a little chore to do: |
| 41 | + |
| 42 | + - a `case` statement must be added in `src/App.js`, which simply perform a dynamic `import()` of the feature |
| 43 | + |
| 44 | + - add a test case in the appropriate integration test file, which calls and awaits `initDOM` with the previous `SwitchCase` string |
| 45 | + |
| 46 | +An usual flow for the test itself is something similar to: |
| 47 | + |
| 48 | + - add an `id` attribute in a target HTML tag in the feature itself |
| 49 | + |
| 50 | + - since `initDOM` returns a `Document` element, the previous `id` attribute is used to target the feature's DOM and `expect` accordingly |
| 51 | + |
| 52 | +These tests are run by **mocha** (why not **jest**? See [this issue](https://github.com/facebook/jest/issues/2288)) and the environments used are both `development` and `production`. |
0 commit comments