Run formatting over *.md files to prevent conflicts

This commit is contained in:
Joe Haddad
2018-10-04 08:37:28 -04:00
parent 61c0ba3731
commit 0473b7d812
7 changed files with 65 additions and 67 deletions

View File

@@ -3,5 +3,5 @@
This package includes scripts and configuration used by [Create React App](https://github.com/facebook/create-react-app).<br>
Please refer to its documentation:
* [Getting Started](https://github.com/facebook/create-react-app/blob/master/README.md#getting-started) How to create a new app.
* [User Guide](https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md) How to develop apps bootstrapped with Create React App.
- [Getting Started](https://github.com/facebook/create-react-app/blob/master/README.md#getting-started) How to create a new app.
- [User Guide](https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md) How to develop apps bootstrapped with Create React App.

View File

@@ -18,11 +18,11 @@ Each time a new feature is added, it is advised to add at least one test coverin
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**
- _env_, all those which deal with environment variables (e.g. `NODE_PATH`)
- *webpack*, all those which make use of webpack settings, loaders or plugins
- _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
@@ -41,13 +41,12 @@ Test are written in `integration/{env|syntax|webpack}.test.js`, depending on the
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
- 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
- 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
- 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