UNPKG

4.2 kBMarkdownView Raw
1## Thank you!
2
3Before anything else, thank you. Thank you for taking some of your precious time helping this project move forward.
4
5This guide will help you get started with Cucumber.js's development environment. You'll also find the set of rules you're expected to follow in order to submit improvements and fixes to Cucumber.js.
6
7## Get started
8
9After forking and cloning the repository, install the required dependencies:
10
11 $ cd <path/to/cucumber-js>
12 $ npm link
13
14## Play
15
16 $ node example/server.js
17
18Then go to [localhost:9797](http://localhost:9797/) to see the little web demo.
19
20## Tests
21
22There are two set of tests resulting from the BDD approach we've been applying to Cucumber.js from the beginning.
23
24* full-stack tests (outside): surprisingly those are Gherkin scenarios;
25* unit tests (inside): jasmine specs.
26
27### Specs
28
29Run the specs:
30
31 $ npm i && npm test
32
33### Features & documentation
34
35There is a common set of features shared by all cucumber implementations. It's called the *Technology Compatibility Kit* or *TCK*. Find more on the [Cucumber TCK](http://github.com/cucumber/cucumber-tck) repository.
36
37The official way of running them is through Cucumber-ruby and Aruba. Ruby and Bundler are required for this to work.
38
39 $ git submodule update --init
40 $ bundle
41 $ rm -rf doc; ARUBA_REPORT_DIR=doc cucumber features/cucumber-tck -r features
42
43*Note*: you need the *bcat* and *rdiscount* gems in order to use the `ARUBA_REPORT_DIR` environment variable. Install it with `gem install bcat rdiscount`.
44
45You can then open the generated documentation:
46
47 $ open doc/features/cucumber-tck/*.html # might open a lot of files ;)
48
49In addition to that, Cucumber.js is able to run the features for itself too:
50
51 $ ./bin/cucumber.js features/cucumber-tck -r features
52
53There are a few other Cucumber.js-dependent features. Execute everything:
54
55 $ ./bin/cucumber.js
56
57### Rake
58
59Alternatively, you can run everything with the help of Rake:
60
61 $ git submodule update --init
62 $ bundle
63 $ rake
64
65### Debug messages
66
67You can display debug messages by setting the DEBUG_LEVEL environment variable. It goes from `1` to `5`. `5` will display everything, `1` will only print out the critical things.
68
69 $ DEBUG_LEVEL=5 ./bin/cucumber.js
70
71It even works with Aruba:
72
73 $ rm -rf doc; DEBUG_LEVEL=5 ARUBA_REPORT_DIR=doc cucumber features/cucumber-tck -r features
74 $ open doc/features/cucumber-tck/*.html # you'll see debug messages in Aruba-generated docs
75
76
77## Coding guidelines
78
79If you plan on submitting code, read this carefully. Please note it is not yet complete.
80
81We stick to the [Google JavaScript Style Guide](http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml).
82
83In addition to those syntactic rules, we apply the following principles:
84
85### Write expressive method and function names
86
87Use expressive names. Express arguments as part of the method/function name. Someone calling it should be able to infer the expected arguments only from the name. They shouldn't have to check the method/function definition.
88
89``` javascript
90adorn(/* ... */) // BAD: it does not tell anything about its
91 // parameters, you'll need to read the method
92 // definition to know the arguments.
93
94addStyleToText(/* ... */) // you can fairly guess this function
95 // accepts "style" and "text" arguments:
96```
97
98** WORK IN PROGRESS **
99
100## Release checklist
101
102This a reminder of the steps maintainers have to follow to release a new version of Cucumber.js.
103
104* Update `History.md`. `git log --format=format:"* %s (%an)" --reverse <last-version-tag>..HEAD` might be handy.
105* Bump version in `lib/cucumber.js`
106* Bump version in `package.json`
107* Bump version in `bower.json`
108* Compile the bundle with `node scripts/release.js`
109* Add new contributors to `package.json`, if any
110* Commit those changes as "*Release 0.1.2*" (where *0.1.2* is the actual version, of course)
111* Tag commit as "v0.1.2" with short description of main changes
112* Push to main repo on GitHub
113* Wait for build to go green
114* Publish to NPM