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
Even though JavaScript is single-threaded, IO in Node.js can happen in parallel due to its async nature. AVA takes advantage of this and runs your tests concurrently, which is especially beneficial for IO heavy tests. [Switching](https://github.com/sindresorhus/pageres/commit/663be15acb3dd2eb0f71b1956ef28c2cd3fdeed0) from Mocha to AVA in Pageres brought the test time down from 31 sec to 11 sec. Having tests run concurrently forces you to write atomic tests, meaning tests that don't depend on global state or the state of other tests, which is a great thing!
8
+
8
9
9
10
## Install
10
11
@@ -15,7 +16,7 @@ $ npm install --save-dev ava
15
16
16
17
## Usage
17
18
18
-
##### Add it to `package.json`
19
+
##### Add it to package.json
19
20
20
21
```json
21
22
{
@@ -25,44 +26,203 @@ $ npm install --save-dev ava
25
26
}
26
27
```
27
28
28
-
Ava accepts files/folders/globs.
29
-
30
29
31
30
##### Create your test file
32
31
33
32
```js
34
33
var test =require('ava');
35
34
36
-
test('test something', function (t) {
37
-
t.is('unicorn', 'unicorn');
35
+
test('foo', function (t) {
36
+
t.pass();
38
37
t.end();
39
38
});
39
+
40
+
test('bar', function (t) {
41
+
t.plan(2)
42
+
43
+
setTimeout(function () {
44
+
t.is('bar', 'bar');
45
+
t.same(['a', 'b'], ['a', 'b']);
46
+
}, 100);
47
+
});
40
48
```
41
49
50
+
<imgsrc="screenshot.png"width="150"align="right">
51
+
42
52
##### Run it
43
53
44
54
```
45
55
$ npm test
46
56
```
47
57
48
58
49
-
## Credit
59
+
## CLI
60
+
61
+
```
62
+
$ ava --help
63
+
64
+
Usage
65
+
ava <file|folder|glob> [...]
66
+
67
+
Examples
68
+
ava
69
+
ava test.js test2.js
70
+
ava test-*.js
71
+
72
+
Default patterns when no arguments:
73
+
test.js test-*.js test/**
74
+
```
75
+
76
+
77
+
## Documentation
78
+
79
+
Test files are just normal Node.js scripts and can be run with `$ node test.js`. However, using the CLI is preferred for simplicity and future [parallelism support](https://github.com/sindresorhus/ava/issues/1).
80
+
81
+
Tests are run async and require you to either set planned assertions `t.plan(1)`, explicitly end the test when done `t.end()`, or return a promise.
82
+
83
+
You have to define all tests synchronously, meaning you can't define a test in the next tick, e.g. inside a `setTimeout`.
84
+
85
+
### Test anatomy
86
+
87
+
To create a test, you just call the `test` function you require'd from AVA and pass in an optional test name and a callback function containing the test execution. The passed callback function is given the context as the first argument where you can call the different AVA methods and assertions.
88
+
89
+
```js
90
+
test('name', function (t) {
91
+
t.pass();
92
+
t.end();
93
+
});
94
+
```
95
+
96
+
### Optional test name
97
+
98
+
Naming a test is optional, but you're recommended to use one if you have more than one test.
99
+
100
+
```js
101
+
test(function (t) {
102
+
t.end();
103
+
});
104
+
```
105
+
106
+
You can also choose to use a named function instead:
107
+
108
+
```js
109
+
test(functionname(t) {
110
+
t.end();
111
+
});
112
+
```
113
+
114
+
### Planned assertions
115
+
116
+
Planned assertions are useful for being able to assert that all async actions happened and catch bugs where too many assertions happen. It also comes with the benefit of not having to manually end the test.
117
+
118
+
This will result in a passed test:
119
+
120
+
```js
121
+
test(function (t) {
122
+
t.plan(1);
123
+
124
+
setTimeout(function () {
125
+
t.pass();
126
+
}, 100);
127
+
});
128
+
```
129
+
130
+
And this will result in an error because the code called more assertions than planned:
131
+
132
+
```js
133
+
test(function (t) {
134
+
t.plan(1);
135
+
136
+
t.pass();
137
+
138
+
setTimeout(function () {
139
+
t.pass();
140
+
}, 100);
141
+
});
142
+
```
143
+
144
+
### Promise support
145
+
146
+
If you return a promise in the test you don't need to explicitly end the test as it will end when the promise resolves.
147
+
148
+
```js
149
+
test(function (t) {
150
+
returnsomePromise().then(function (result) {
151
+
t.is(result, 'unicorn');
152
+
});
153
+
});
154
+
```
155
+
156
+
157
+
### Serial test execution
158
+
159
+
While concurrency is awesome, there are some things that can't be done concurrently. In these rare cases, you can call `test.serial`, which will force those tests to run serially before the concurrent ones.
160
+
161
+
```js
162
+
test.serial(function (t) {
163
+
t.end();
164
+
});
165
+
```
166
+
167
+
168
+
## API
169
+
170
+
### test([name], body)
171
+
### test.serial([name], body)
172
+
173
+
#### name
174
+
175
+
Type: `string`
176
+
177
+
Test name.
178
+
179
+
#### body(context)
180
+
181
+
Type: `function`
182
+
183
+
Should contain the actual test.
184
+
185
+
##### context
186
+
187
+
Passed into the test function and contains the different AVA methods and assertions.
188
+
189
+
See the [`claim` docs](https://github.com/kevva/claim#api) for supported assertions.
190
+
191
+
###### plan(count)
192
+
193
+
Plan how many assertion there are in the test. The test will fail if the actual assertion count doesn't match planned assertions. When planned assertions are used you don't need to explicitly end the test.
194
+
195
+
Be aware that this doesn't work with custom assert modules. You must then call `.end()` explicitly.
196
+
197
+
###### end()
198
+
199
+
End the test. Use this when `plan()` is not used.
200
+
201
+
202
+
## Tips
203
+
204
+
### Temp files
205
+
206
+
Running tests concurrently comes with some challenges, doing IO is one. Usually, serial tests just create temp directories in the current test directory and cleans it up at the end. This won't work when you run tests concurrently as tests will conflict with each other. The correct way to do it is to use a new temp directory for each test. The [`tempfile`](https://github.com/sindresorhus/tempfile) and [`temp-write`](https://github.com/sindresorhus/temp-write) modules can be helpful.
Mocha requires you to use implicit globals like `describe` and `it`, too unopinionated, bloated, synchronous by default, serial test execution, and slow. Tape and node-tap are pretty good. AVA is highly inspired by their syntax. However, they both execute tests serially and they've made [TAP](https://testanything.org) a first-class citizen which has IMHO made their codebases a bit convoluted and coupled. TAP output is hard to read so you always end up using an external tap reporter. AVA is highly opinionated and concurrent. It comes with a default simple reporter and will in the future support TAP through a reporter.
0 commit comments