You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+83-28
Original file line number
Diff line number
Diff line change
@@ -11,33 +11,28 @@ Submitting code to the project? Please review and follow our
11
11
12
12
### Code Quality
13
13
14
-
Although we do not have official code style guidelines, we can and will request you to make changes
15
-
if we think that your code is sloppy. You can take clues from the existing code base to see what we
16
-
consider to be reasonable code quality. Please be prepared to make changes that we ask of you even
17
-
if you might not agree with the request(s).
14
+
Although we do not have official code style guidelines, we can and will request you to make changes if we feel the changes are warranted. You can take clues from the existing code base to see what we consider to be reasonable code quality. Please be prepared to make changes that we ask of you even if you might not agree with the request(s).
18
15
19
16
Please respect the coding style of the files you are changing and adhere to that.
20
17
21
-
The JavaScript files in this project are formatted by [Prettier](https://prettier.io/). Additionally, we prefer:
18
+
The files in this project are formatted by [Prettier](https://prettier.io/) and [ESLint](https://eslint.org/). Both are run when code is committed. Additionally, you can run ESLint manually:
22
19
23
-
1. Tabs over spaces
24
-
2. Single quotes for string literals
25
-
3. Function definitions like `function functionName(arguments) {`
26
-
4. Variable function definitions like `Class.prototype.functionName = function (arguments) {`
27
-
5. Use of 'use strict'
28
-
6. Variables declared at the top of functions
20
+
```console
21
+
npm run eslint
22
+
```
29
23
30
24
### Shadow DOM
31
25
32
-
For any proposed changes to rules, checks, commons, or other APIs to be accepted
33
-
in axe-core, your code must support open Shadow DOM. See [API.md](./doc/API.md) and the
34
-
[developer guide](./doc/developer-guide.md) for documentation on the available methods
35
-
and test utilities. You can also look at existing tests for examples using our APIs.
26
+
For any proposed changes to rules, checks, commons, or other APIs to be accepted in axe-core, your code must support open Shadow DOM. See [API.md](./doc/API.md) and the [developer guide](./doc/developer-guide.md) for documentation on the available methods and test utilities. You can also look at existing tests for examples using our APIs.
36
27
37
28
### Testing
38
29
39
30
We expect all code to be 100% covered by tests. We don't have or want code coverage metrics but we will review tests and suggest changes when we think the test(s) do(es) not adequately exercise the code/code changes.
40
31
32
+
Tests should be added to the `test` directory using the same file path and name of the source file the test is for. For example, the source file `lib/commons/text/sanitize.js` should have a test file at `test/commons/text/sanitize.js`.
33
+
34
+
Axe uses Karma / Mocha / Chai as its testing framework.
35
+
41
36
### Documentation and Comments
42
37
43
38
Functions should contain a preceding comment block with [jsdoc](http://usejsdoc.org/) style documentation of the function. For example:
@@ -60,8 +55,6 @@ Classes should contain a jsdoc comment block for each attribute. For example:
60
55
* @param{Object}check CheckResult specification
61
56
*/
62
57
functionCheckResult(check) {
63
-
'use strict';
64
-
65
58
/**
66
59
* ID of the check. Unique in the context of a rule.
67
60
* @type{String}
@@ -98,34 +91,96 @@ Once the basic infrastructure is installed, from the repository root, do the fol
98
91
npm install
99
92
```
100
93
101
-
To run tests:
94
+
Then build the package:
102
95
103
96
```console
104
-
grunt test
97
+
npm run build
105
98
```
106
99
107
-
To build the package:
100
+
## Developing and testing
101
+
102
+
In order to run axe tests, `axe.js` must be built using `npm run build`. To run the unit tests:
108
103
109
104
```console
110
-
grunt build
105
+
npm test
111
106
```
112
107
113
-
## Using axe with TypeScript
108
+
To continually watch changes to the axe source files and re-build on changes, use:
114
109
115
-
### Axe Development
110
+
```console
111
+
npm run develop
112
+
```
116
113
117
-
The TypeScript definition file for axe-core is distributed with this module and can be found in [axe.d.ts](./axe.d.ts). It currently supports TypeScript 2.0+.
114
+
This will also rerun any tests that have been changed, and any changes to the axe source files will trigger a rerun of that files tests.
115
+
116
+
To run axe integration tests:
117
+
118
+
```console
119
+
npm run test:integration
120
+
```
121
+
122
+
Lastly, there are a few other tests that get run during the continuous integration process:
123
+
124
+
```console
125
+
# run the tests from `doc/examples/*` using the current local build of `axe.js`
126
+
npm run test:examples
127
+
128
+
# run the tests from `test/node`
129
+
npm run test:node
130
+
```
131
+
132
+
### Running and debugging specific unit tests
118
133
119
-
To maintain axe support for TypeScript you must first install it (globally recommended):
134
+
If you want to run a specific set of unit tests instead of all the unit tests, you can use one of the following commands:
120
135
121
136
```console
122
-
sudo npm -g install typescript
137
+
# run just the tests from `test/core`
138
+
npm run test:unit:core
139
+
140
+
# run just the tests from `test/commons`
141
+
npm run test:unit:commons
142
+
143
+
# run just the tests from `test/rule-matches`
144
+
npm run test:unit:rule-matches
145
+
146
+
# run just the tests from `test/checks`
147
+
npm run test:unit:checks
148
+
149
+
# run just the tests from `test/integration/rules`
150
+
npm run test:unit:integration
151
+
152
+
# run just the tests from `test/integration/api`
153
+
npm run test:unit:api
154
+
155
+
# run just the tests from `test/integration/virtual-rules`
156
+
npm run test:unit:virtual-rules
123
157
```
124
158
125
-
Once that's installed, you can run TypeScript definition tests (with the optional `--noImplicitAny` flag):
159
+
If you need to debug the unit tests in a browser, you can run:
160
+
161
+
```console
162
+
npm run test:debug
163
+
```
164
+
165
+
This will start the Karma server and open up the Chrome browser. Click the `Debug` button to start debugging the tests. You can also navigate to the listed URL in your browser of choice to debug tests using that browser.
166
+
167
+
Because the amount of tests is so large, it's recommended to debug only a specific set of unit tests rather than the whole test suite. You can use the `testDirs` argument when using the debug command and pass a specific test directory. The test directory names are the same as those used for `test:unit:*`:
168
+
169
+
```console
170
+
# accepts a single directory or a comma-separated list of directories
171
+
npm run test:debug -- testDirs=core,commons
172
+
```
173
+
174
+
## Using axe with TypeScript
175
+
176
+
### Axe Development
177
+
178
+
The TypeScript definition file for axe-core is distributed with this module and can be found in [axe.d.ts](./axe.d.ts). It currently supports TypeScript 2.0+.
179
+
180
+
You can run TypeScript definition tests using the following command:
0 commit comments