@@ -219,10 +219,10 @@ fn it_works() {
219
219
This is a very common use of ` assert_eq! ` : call some function with
220
220
some known arguments and compare it to the expected output.
221
221
222
- # The ` test ` module
222
+ # The ` tests ` module
223
223
224
224
There is one way in which our existing example is not idiomatic: it's
225
- missing the test module. The idiomatic way of writing our example
225
+ missing the ` tests ` module. The idiomatic way of writing our example
226
226
looks like this:
227
227
228
228
``` {rust,ignore}
@@ -231,7 +231,7 @@ pub fn add_two(a: i32) -> i32 {
231
231
}
232
232
233
233
#[cfg(test)]
234
- mod test {
234
+ mod tests {
235
235
use super::add_two;
236
236
237
237
#[test]
@@ -241,7 +241,7 @@ mod test {
241
241
}
242
242
```
243
243
244
- There's a few changes here. The first is the introduction of a ` mod test ` with
244
+ There's a few changes here. The first is the introduction of a ` mod tests ` with
245
245
a ` cfg ` attribute. The module allows us to group all of our tests together, and
246
246
to also define helper functions if needed, that don't become a part of the rest
247
247
of our crate. The ` cfg ` attribute only compiles our test code if we're
@@ -260,7 +260,7 @@ pub fn add_two(a: i32) -> i32 {
260
260
}
261
261
262
262
#[cfg(test)]
263
- mod test {
263
+ mod tests {
264
264
use super::*;
265
265
266
266
#[test]
@@ -279,7 +279,7 @@ $ cargo test
279
279
Running target/adder-91b3e234d4ed382a
280
280
281
281
running 1 test
282
- test test ::it_works ... ok
282
+ test tests ::it_works ... ok
283
283
284
284
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
285
285
@@ -292,7 +292,7 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
292
292
293
293
It works!
294
294
295
- The current convention is to use the ` test ` module to hold your "unit-style"
295
+ The current convention is to use the ` tests ` module to hold your "unit-style"
296
296
tests. Anything that just tests one small bit of functionality makes sense to
297
297
go here. But what about "integration-style" tests instead? For that, we have
298
298
the ` tests ` directory
@@ -325,7 +325,7 @@ $ cargo test
325
325
Running target/adder-91b3e234d4ed382a
326
326
327
327
running 1 test
328
- test test ::it_works ... ok
328
+ test tests ::it_works ... ok
329
329
330
330
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
331
331
@@ -346,7 +346,7 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
346
346
Now we have three sections: our previous test is also run, as well as our new
347
347
one.
348
348
349
- That's all there is to the ` tests ` directory. The ` test ` module isn't needed
349
+ That's all there is to the ` tests ` directory. The ` tests ` module isn't needed
350
350
here, since the whole thing is focused on tests.
351
351
352
352
Let's finally check out that third section: documentation tests.
@@ -382,7 +382,7 @@ pub fn add_two(a: i32) -> i32 {
382
382
}
383
383
384
384
#[cfg(test)]
385
- mod test {
385
+ mod tests {
386
386
use super::*;
387
387
388
388
#[test]
@@ -405,7 +405,7 @@ $ cargo test
405
405
Running target/adder-91b3e234d4ed382a
406
406
407
407
running 1 test
408
- test test ::it_works ... ok
408
+ test tests ::it_works ... ok
409
409
410
410
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
411
411
0 commit comments