12
12
fixtures and table-based tests. To use it, add the
13
13
following lines to your ` Cargo.toml ` file:
14
14
15
- ```
15
+ ``` toml
16
16
[dev-dependencies ]
17
17
rstest = " 0.18.2"
18
18
```
@@ -96,8 +96,8 @@ values.
96
96
97
97
#### Use Parametrize definition in more tests
98
98
99
- If you need to use a test list for more than one test you can use [ ` rstest_reuse ` ] [ reuse-crate-link ]
100
- crate. With this helper crate you can define a template and use it everywhere .
99
+ If you need to use a test list for more than one test you can use [ ` rstest_reuse ` ] [ reuse-crate-link ]
100
+ crate. With this helper crate you can define a template and use it everywhere.
101
101
102
102
``` rust
103
103
use rstest :: rstest;
@@ -115,11 +115,11 @@ fn it_works(#[case] a: u32, #[case] b: u32) {
115
115
}
116
116
```
117
117
118
- See [ ` rstest_reuse ` ] [ reuse-crate-link ] for more dettails .
118
+ See [ ` rstest_reuse ` ] [ reuse-crate-link ] for more details .
119
119
120
120
### Magic Conversion
121
121
122
- If you need a value where its type implement ` FromStr() ` trait you can use a literal
122
+ If you need a value where its type implement ` FromStr() ` trait you can use a literal
123
123
string to build it:
124
124
125
125
``` rust
@@ -132,12 +132,13 @@ fn check_port(#[case] addr: SocketAddr, #[case] expected: u16) {
132
132
assert_eq! (expected , addr . port ());
133
133
}
134
134
```
135
+
135
136
You can use this feature also in value list and in fixture default value.
136
137
137
138
### Async
138
139
139
140
` rstest ` provides out of the box ` async ` support. Just mark your
140
- test function as ` async ` and it'll use ` #[async-std::test] ` to
141
+ test function as ` async ` , and it'll use ` #[async-std::test] ` to
141
142
annotate it. This feature can be really useful to build async
142
143
parametric tests using a tidy syntax:
143
144
@@ -152,8 +153,9 @@ async fn my_async_test(#[case] expected: u32, #[case] a: u32, #[case] b: u32) {
152
153
assert_eq! (expected , async_sum (a , b ). await );
153
154
}
154
155
```
155
- Currently only ` async-std ` is supported out of the box. But if you need to use
156
- another runtime that provide it's own test attribute (i.e. ` tokio::test ` or
156
+
157
+ Currently, only ` async-std ` is supported out of the box. But if you need to use
158
+ another runtime that provide its own test attribute (i.e. ` tokio::test ` or
157
159
` actix_rt::test ` ) you can use it in your ` async ` test like described in
158
160
[ Inject Test Attribute] ( #inject-test-attribute ) .
159
161
@@ -180,7 +182,7 @@ async fn my_async_test(#[future] base: u32, #[case] expected: u32, #[future] #[c
180
182
}
181
183
```
182
184
183
- As you noted you should ` .await ` all _ future_ values and this some times can be really boring.
185
+ As you noted you should ` .await ` all _ future_ values and this sometimes can be really boring.
184
186
In this case you can use ` #[future(awt)] ` to _ awaiting_ an input or annotating your function
185
187
with ` #[awt] ` attributes to globally ` .await ` all your _ future_ inputs. Previous code can be
186
188
simplified like follow:
@@ -217,9 +219,9 @@ fn for_each_file(#[files("src/**/*.rs")] #[exclude("test")] path: PathBuf) {
217
219
}
218
220
```
219
221
220
- The default behavior is to ignore the files that starts with ` "." ` but you can
222
+ The default behavior is to ignore the files that start with ` "." ` , but you can
221
223
modify this by use ` #[include_dot_files] ` attribute. The ` files ` attribute can be
222
- used more than once on the same variable and you can also create some custom
224
+ used more than once on the same variable, and you can also create some custom
223
225
exclusion rules with the ` #[exclude("regex")] ` attributes that filter out all
224
226
paths that verify the regular expression.
225
227
@@ -249,12 +251,13 @@ async fn single_pass() {
249
251
assert_eq! (4 , delayed_sum (2 , 2 , ms (10 )). await );
250
252
}
251
253
```
254
+
252
255
In this case test pass because the delay is just 10 milliseconds and timeout is
253
256
80 milliseconds.
254
257
255
- You can use ` timeout ` attribute like any other attibute in your tests and you can
258
+ You can use ` timeout ` attribute like any other attribute in your tests, and you can
256
259
override a group timeout with a case specific one. In the follow example we have
257
- 3 tests where first and third use 100 millis but the second one use 10 millis .
260
+ 3 tests where first and third use 100 milliseconds but the second one use 10 milliseconds .
258
261
Another valuable point in this example is to use an expression to compute the
259
262
duration.
260
263
@@ -279,7 +282,7 @@ feature (enabled by default).
279
282
280
283
### Inject Test Attribute
281
284
282
- If you would like to use another ` test ` attribute for your test you can simply
285
+ If you would like to use another ` test ` attribute for your test you can simply
283
286
indicate it in your test function's attributes. For instance if you want
284
287
to test some async function with use ` actix_rt::test ` attribute you can just write:
285
288
@@ -296,11 +299,12 @@ async fn my_async_test(#[case] a: u32, #[case] #[future] result: u32) {
296
299
assert_eq! (2 * a , result . await );
297
300
}
298
301
```
302
+
299
303
Just the attributes that ends with ` test ` (last path segment) can be injected.
300
304
301
305
### Use ` #[once] ` Fixture
302
306
303
- If you need to a fixture that should be inizialized just once for all tests
307
+ If you need to a fixture that should be initialized just once for all tests
304
308
you can use ` #[once] ` attribute. ` rstest ` call your fixture function just once and
305
309
return a reference to your function result to all your tests:
306
310
@@ -317,12 +321,11 @@ fn single(once_fixture: &i32) {
317
321
}
318
322
```
319
323
320
-
321
324
## Complete Example
322
325
323
326
All these features can be used together with a mixture of fixture variables,
324
- fixed cases and bunch of values. For instance, you might need two
325
- test cases which test for panics, one for a logged in user and one for a guest user.
327
+ fixed cases and a bunch of values. For instance, you might need two
328
+ test cases which test for panics, one for a logged- in user and one for a guest user.
326
329
327
330
``` rust
328
331
use rstest :: * ;
@@ -340,10 +343,10 @@ fn alice() -> User {
340
343
}
341
344
342
345
#[rstest]
343
- #[case:: authed_user (alice())] // We can use `fixture` also as standard function
346
+ #[case:: authorized_user (alice())] // We can use `fixture` also as standard function
344
347
#[case:: guest(User :: Guest )] // We can give a name to every case : `guest` in this case
345
- // and `authed_user `
346
- #[should_panic(expected = " Invalid query error" )] // We whould test a panic
348
+ // and `authorized_user `
349
+ #[should_panic(expected = " Invalid query error" )] // We would test a panic
347
350
fn should_be_invalid_query_error (
348
351
repository : impl Repository ,
349
352
#[case ] user : User ,
@@ -354,26 +357,27 @@ fn should_be_invalid_query_error(
354
357
```
355
358
356
359
This example will generate exactly 6 tests grouped by 2 different cases:
357
- ```
360
+
361
+ ``` text
358
362
running 6 tests
359
- test should_be_invalid_query_error::case_1_authed_user ::query_1_____ - should panic ... ok
363
+ test should_be_invalid_query_error::case_1_authorized_user ::query_1_____ - should panic ... ok
360
364
test should_be_invalid_query_error::case_2_guest::query_2_____someinvalid_chars__ - should panic ... ok
361
- test should_be_invalid_query_error::case_1_authed_user ::query_2_____someinvalid_chars__ - should panic ... ok
365
+ test should_be_invalid_query_error::case_1_authorized_user ::query_2_____someinvalid_chars__ - should panic ... ok
362
366
test should_be_invalid_query_error::case_2_guest::query_3____n_o_d_o_t_s___ - should panic ... ok
363
- test should_be_invalid_query_error::case_1_authed_user ::query_3____n_o_d_o_t_s___ - should panic ... ok
367
+ test should_be_invalid_query_error::case_1_authorized_user ::query_3____n_o_d_o_t_s___ - should panic ... ok
364
368
test should_be_invalid_query_error::case_2_guest::query_1_____ - should panic ... ok
365
369
366
370
test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
367
371
```
368
372
369
- Note that the names of the values _ try_ to convert the input expression in a
370
- Rust valid identifier name to help you to find which tests fail.
373
+ Note that the names of the values _ try_ to convert the input expression in a
374
+ Rust valid identifier name to help you find which tests fail.
371
375
372
376
## More
373
377
374
378
Is that all? Not quite yet!
375
379
376
- A fixture can be injected by another fixture and they can be called
380
+ A fixture can be injected by another fixture, and they can be called
377
381
using just some of its arguments.
378
382
379
383
``` rust
@@ -406,21 +410,21 @@ fn is_42(#[with("", 42)] user: User) {
406
410
As you noted you can provide default values without the need of a fixture
407
411
to define it.
408
412
409
- Finally if you need tracing the input values you can just
413
+ Finally, if you need tracing the input values you can just
410
414
add the ` trace ` attribute to your test to enable the dump of all input
411
415
variables.
412
416
413
417
``` rust
414
418
#[rstest]
415
419
#[case(42, " FortyTwo" , (" minus twelve" , - 12))]
416
420
#[case(24, " TwentyFour" , (" minus twentyfour" , - 24))]
417
- #[trace] // This attribute enable traceing
421
+ #[trace] // This attribute enable tracing
418
422
fn should_fail (#[case ] number : u32 , #[case ] name : & str , #[case ] tuple : (& str , i32 )) {
419
423
assert! (false ); // <- stdout come out just for failed tests
420
424
}
421
425
```
422
426
423
- ```
427
+ ``` text
424
428
running 2 tests
425
429
test should_fail::case_1 ... FAILED
426
430
test should_fail::case_2 ... FAILED
@@ -456,7 +460,7 @@ In case one or more variables don't implement the `Debug` trait, an error
456
460
is raised, but it's also possible to exclude a variable using the
457
461
` #[notrace] ` argument attribute.
458
462
459
- You can learn more on [ Docs] [ docs-link ] and find more examples in
463
+ You can learn more on [ Docs] [ docs-link ] and find more examples in
460
464
[ ` tests/resources ` ] ( tests/resources ) directory.
461
465
462
466
## Changelog
0 commit comments