Before anything else, thank you. Thank you for taking some of your precious time helping this project move forward.
See the package.json
scripts section for how to run the tests.
- lint
- unit tests
- feature tests
- cucumber-js tests itself
- Run
yarn build-browser-example
- Run
node scripts/server.js
- Visit
localhost:9797
.
The published browser example is only updated when releasing a new version.
└── src
│
├── cli # argv parsing, reading files
│
├── formatter # displaying the results
│
├── models # data structures
│
├── runtime # run test cases, emits the event protocol
│
└── support_code_library # load hooks / step definitions
The runtime emits events with an EventEmitter
- Promises and ES7 async/await
- Try to make things as unit testable as possible. If its hard to unit test, the class/function may be doing too much.
The following is a checklist for maintainers when preparing a new release
Perform the following steps on a feature branch.
- Update
CHANGELOG.md
- Describe the major changes introduced. API changes must be documented. In particular, backward-incompatible changes must be well explained, with examples when possible.
git log --format=format:"* %s (%an)" --reverse <last-version-tag>..HEAD
might be handy.
- Update
package.json
- bump version
- add new contributors, if any
git log --format=format:"%an <%ae>" --reverse <last-version-tag>..HEAD
- Compile the bundle with
yarn run build-release
- Ensure the browser example works
Review the changes, if everything looks good, squash merge into master.
- commit message should have the format "Release 0.1.2" (replacing 0.1.2 with the actual version)
- Tag commit as "v0.1.2"
- CI will publish to NPM
- Update docs.cucumber.io
- Update the cucumber-js version
data/versions.yaml
- Ensure the javascript examples are up to date
- Update the cucumber-js version