From 15e2d39b4b8b457cd2b732f84d0445bdb6aedf17 Mon Sep 17 00:00:00 2001 From: la10736 Date: Sun, 13 Aug 2023 09:00:52 +0200 Subject: [PATCH] Fixed lot of spell mistakes --- CHANGELOG.md | 4 +-- README.md | 68 +++++++++++++++++++++------------------- rstest_macros/src/lib.rs | 54 +++++++++++++++---------------- 3 files changed, 65 insertions(+), 61 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 33f937cc..0677513c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,8 +4,8 @@ ### Changed -- Now `#[files]` accept also parent folders: see [#205](https://github.com/la10736/rstest/issues/205) -for more details. +- Now `#[files]` accept also parent folders (see [#205](https://github.com/la10736/rstest/issues/205) +for more details). ## [0.18.1] 2023/7/5 diff --git a/README.md b/README.md index f47ff940..a6b1733f 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ fixtures and table-based tests. To use it, add the following lines to your `Cargo.toml` file: -``` +```toml [dev-dependencies] rstest = "0.18.2" ``` @@ -96,8 +96,8 @@ values. #### Use Parametrize definition in more tests -If you need to use a test list for more than one test you can use [`rstest_reuse`][reuse-crate-link] -crate. With this helper crate you can define a template and use it everywhere . +If you need to use a test list for more than one test you can use [`rstest_reuse`][reuse-crate-link] +crate. With this helper crate you can define a template and use it everywhere. ```rust use rstest::rstest; @@ -115,11 +115,11 @@ fn it_works(#[case] a: u32, #[case] b: u32) { } ``` -See [`rstest_reuse`][reuse-crate-link] for more dettails. +See [`rstest_reuse`][reuse-crate-link] for more details. ### Magic Conversion -If you need a value where its type implement `FromStr()` trait you can use a literal +If you need a value where its type implement `FromStr()` trait you can use a literal string to build it: ```rust @@ -132,12 +132,13 @@ fn check_port(#[case] addr: SocketAddr, #[case] expected: u16) { assert_eq!(expected, addr.port()); } ``` + You can use this feature also in value list and in fixture default value. ### Async `rstest` provides out of the box `async` support. Just mark your -test function as `async` and it'll use `#[async-std::test]` to +test function as `async`, and it'll use `#[async-std::test]` to annotate it. This feature can be really useful to build async parametric tests using a tidy syntax: @@ -152,8 +153,9 @@ async fn my_async_test(#[case] expected: u32, #[case] a: u32, #[case] b: u32) { assert_eq!(expected, async_sum(a, b).await); } ``` -Currently only `async-std` is supported out of the box. But if you need to use -another runtime that provide it's own test attribute (i.e. `tokio::test` or + +Currently, only `async-std` is supported out of the box. But if you need to use +another runtime that provide its own test attribute (i.e. `tokio::test` or `actix_rt::test`) you can use it in your `async` test like described in [Inject Test Attribute](#inject-test-attribute). @@ -180,7 +182,7 @@ async fn my_async_test(#[future] base: u32, #[case] expected: u32, #[future] #[c } ``` -As you noted you should `.await` all _future_ values and this some times can be really boring. +As you noted you should `.await` all _future_ values and this sometimes can be really boring. In this case you can use `#[future(awt)]` to _awaiting_ an input or annotating your function with `#[awt]` attributes to globally `.await` all your _future_ inputs. Previous code can be simplified like follow: @@ -217,9 +219,9 @@ fn for_each_file(#[files("src/**/*.rs")] #[exclude("test")] path: PathBuf) { } ``` -The default behavior is to ignore the files that starts with `"."` but you can +The default behavior is to ignore the files that start with `"."`, but you can modify this by use `#[include_dot_files]` attribute. The `files` attribute can be -used more than once on the same variable and you can also create some custom +used more than once on the same variable, and you can also create some custom exclusion rules with the `#[exclude("regex")]` attributes that filter out all paths that verify the regular expression. @@ -249,12 +251,13 @@ async fn single_pass() { assert_eq!(4, delayed_sum(2, 2, ms(10)).await); } ``` + In this case test pass because the delay is just 10 milliseconds and timeout is 80 milliseconds. -You can use `timeout` attribute like any other attibute in your tests and you can +You can use `timeout` attribute like any other attribute in your tests, and you can override a group timeout with a case specific one. In the follow example we have -3 tests where first and third use 100 millis but the second one use 10 millis. +3 tests where first and third use 100 milliseconds but the second one use 10 milliseconds. Another valuable point in this example is to use an expression to compute the duration. @@ -279,7 +282,7 @@ feature (enabled by default). ### Inject Test Attribute -If you would like to use another `test` attribute for your test you can simply +If you would like to use another `test` attribute for your test you can simply indicate it in your test function's attributes. For instance if you want to test some async function with use `actix_rt::test` attribute you can just write: @@ -296,11 +299,12 @@ async fn my_async_test(#[case] a: u32, #[case] #[future] result: u32) { assert_eq!(2 * a, result.await); } ``` + Just the attributes that ends with `test` (last path segment) can be injected. ### Use `#[once]` Fixture -If you need to a fixture that should be inizialized just once for all tests +If you need to a fixture that should be initialized just once for all tests you can use `#[once]` attribute. `rstest` call your fixture function just once and return a reference to your function result to all your tests: @@ -317,12 +321,11 @@ fn single(once_fixture: &i32) { } ``` - ## Complete Example All these features can be used together with a mixture of fixture variables, -fixed cases and bunch of values. For instance, you might need two -test cases which test for panics, one for a logged in user and one for a guest user. +fixed cases and a bunch of values. For instance, you might need two +test cases which test for panics, one for a logged-in user and one for a guest user. ```rust use rstest::*; @@ -340,10 +343,10 @@ fn alice() -> User { } #[rstest] -#[case::authed_user(alice())] // We can use `fixture` also as standard function +#[case::authorized_user(alice())] // We can use `fixture` also as standard function #[case::guest(User::Guest)] // We can give a name to every case : `guest` in this case - // and `authed_user` -#[should_panic(expected = "Invalid query error")] // We whould test a panic + // and `authorized_user` +#[should_panic(expected = "Invalid query error")] // We would test a panic fn should_be_invalid_query_error( repository: impl Repository, #[case] user: User, @@ -354,26 +357,27 @@ fn should_be_invalid_query_error( ``` This example will generate exactly 6 tests grouped by 2 different cases: -``` + +```text running 6 tests -test should_be_invalid_query_error::case_1_authed_user::query_1_____ - should panic ... ok +test should_be_invalid_query_error::case_1_authorized_user::query_1_____ - should panic ... ok test should_be_invalid_query_error::case_2_guest::query_2_____someinvalid_chars__ - should panic ... ok -test should_be_invalid_query_error::case_1_authed_user::query_2_____someinvalid_chars__ - should panic ... ok +test should_be_invalid_query_error::case_1_authorized_user::query_2_____someinvalid_chars__ - should panic ... ok test should_be_invalid_query_error::case_2_guest::query_3____n_o_d_o_t_s___ - should panic ... ok -test should_be_invalid_query_error::case_1_authed_user::query_3____n_o_d_o_t_s___ - should panic ... ok +test should_be_invalid_query_error::case_1_authorized_user::query_3____n_o_d_o_t_s___ - should panic ... ok test should_be_invalid_query_error::case_2_guest::query_1_____ - should panic ... ok test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s ``` -Note that the names of the values _try_ to convert the input expression in a -Rust valid identifier name to help you to find which tests fail. +Note that the names of the values _try_ to convert the input expression in a +Rust valid identifier name to help you find which tests fail. ## More Is that all? Not quite yet! -A fixture can be injected by another fixture and they can be called +A fixture can be injected by another fixture, and they can be called using just some of its arguments. ```rust @@ -406,7 +410,7 @@ fn is_42(#[with("", 42)] user: User) { As you noted you can provide default values without the need of a fixture to define it. -Finally if you need tracing the input values you can just +Finally, if you need tracing the input values you can just add the `trace` attribute to your test to enable the dump of all input variables. @@ -414,13 +418,13 @@ variables. #[rstest] #[case(42, "FortyTwo", ("minus twelve", -12))] #[case(24, "TwentyFour", ("minus twentyfour", -24))] -#[trace] //This attribute enable traceing +#[trace] //This attribute enable tracing fn should_fail(#[case] number: u32, #[case] name: &str, #[case] tuple: (&str, i32)) { assert!(false); // <- stdout come out just for failed tests } ``` -``` +```text running 2 tests test should_fail::case_1 ... FAILED test should_fail::case_2 ... FAILED @@ -456,7 +460,7 @@ In case one or more variables don't implement the `Debug` trait, an error is raised, but it's also possible to exclude a variable using the `#[notrace]` argument attribute. -You can learn more on [Docs][docs-link] and find more examples in +You can learn more on [Docs][docs-link] and find more examples in [`tests/resources`](tests/resources) directory. ## Changelog diff --git a/rstest_macros/src/lib.rs b/rstest_macros/src/lib.rs index c1347dba..553e051f 100644 --- a/rstest_macros/src/lib.rs +++ b/rstest_macros/src/lib.rs @@ -139,7 +139,7 @@ use quote::ToTokens; /// /// # `#[once]` Fixture /// -/// Expecially in integration tests there are cases where you need a fixture that is called just once +/// Especially in integration tests there are cases where you need a fixture that is called just once /// for every tests. `rstest` provides `#[once]` attribute for these cases. /// /// If you mark your fixture with this attribute, then `rstest` will compute a static reference to your @@ -180,7 +180,7 @@ use quote::ToTokens; /// /// # Partial Injection /// -/// You can also partialy inject fixture dependency using `#[with(v1, v2, ..)]` attribute: +/// You can also partially inject fixture dependency using `#[with(v1, v2, ..)]` attribute: /// /// ``` /// use rstest::*; @@ -206,7 +206,7 @@ use quote::ToTokens; /// attribute will inject `v1, ..., vn` expression as fixture arguments: all remaining arguments /// will be resolved as fixtures. /// -/// Sometimes the return type cannot be infered so you must define it: For the few times you may +/// Sometimes the return type cannot be inferred so you must define it: For the few times you may /// need to do it, you can use the `#[default(type)]`, `#[partial_n(type)]` function attribute /// to define it: /// @@ -245,8 +245,8 @@ use quote::ToTokens; /// /// # Old _compact_ syntax /// -/// There is also a compact form for all previous features. This will mantained for a long time -/// but for `fixture` I strongly recomand to migrate your code because you'll pay a little +/// There is also a compact form for all previous features. This will maintained for a long time +/// but for `fixture` I strongly recommend to migrate your code because you'll pay a little /// verbosity but get back a more readable code. /// /// Follow the previous examples in old _compact_ syntax. @@ -360,7 +360,7 @@ pub fn fixture( /// The simplest case is write a test that can be injected with /// [`[fixture]`](macro@fixture)s. You can just declare all used fixtures by passing /// them as a function's arguments. This can help your test to be neat -/// and make your dependecy clear. +/// and make your dependency clear. /// /// ``` /// use rstest::*; @@ -401,7 +401,7 @@ pub fn fixture( /// } /// ``` /// -/// Sometimes is useful to have some parametes in your fixtures but your test would +/// Sometimes is useful to have some parameters in your fixtures but your test would /// override the fixture's default values in some cases. Like in /// [fixture partial injection](attr.fixture.html#partial-injection) you use `#[with]` /// attribute to indicate some fixture's arguments also in `rstest`. @@ -452,8 +452,8 @@ pub fn fixture( /// } /// ``` /// -/// `rstest` will produce 5 indipendent tests and not just one that -/// check every case. Every test can fail indipendently and `cargo test` +/// `rstest` will produce 5 independent tests and not just one that +/// check every case. Every test can fail independently and `cargo test` /// will give follow output: /// /// ```text @@ -467,7 +467,7 @@ pub fn fixture( /// test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out /// ``` /// -/// The cases input values can be arbitrary Rust expresions that return the +/// The cases input values can be arbitrary Rust expressions that return the /// argument type. /// /// ``` @@ -495,7 +495,7 @@ pub fn fixture( /// # fn count_words(path: PathBuf) -> usize {0} /// #[rstest] /// #[case("resources/empty", 0)] -/// #[case("resources/divine_commedy", 101.698)] +/// #[case("resources/divine_comedy", 101.698)] /// fn test_count_words(#[case] path: PathBuf, #[case] expected: usize) { /// assert_eq!(expected, count_words(path)) /// } @@ -527,7 +527,7 @@ pub fn fixture( /// # } /// ``` /// -/// Outuput will be +/// Output will be /// ```text /// running 4 tests /// test fibonacci_test::case_1_zero_base_case ... ok @@ -596,7 +596,7 @@ pub fn fixture( /// ## Values Lists /// /// Another useful way to write a test and execute it for some values -/// is to use the values list syntax. This syntax can be usefull both +/// is to use the values list syntax. This syntax can be useful both /// for a plain list and for testing all combination of input arguments. /// /// ``` @@ -605,7 +605,7 @@ pub fn fixture( /// /// #[rstest] /// fn should_be_valid( -/// #[values("Jhon", "alice", "My_Name", "Zigy_2001")] +/// #[values("John", "alice", "My_Name", "Zigy_2001")] /// input: &str /// ) { /// assert!(is_valid(input)) @@ -641,7 +641,7 @@ pub fn fixture( /// test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s /// ``` /// Note that the test names contains the given expression sanitized into -/// a valid Rust identifier name. This should help to identify wich case fails. +/// a valid Rust identifier name. This should help to identify which case fails. /// /// /// Also value list implements the magic conversion feature: every time the value type @@ -671,17 +671,17 @@ pub fn fixture( /// assert!(check_file(&path)) /// } /// ``` -/// The default behavior is to ignore the files that starts with `"."` but you can +/// The default behavior is to ignore the files that start with `"."`, but you can /// modify this by use `#[include_dot_files]` attribute. The `files` attribute can be -/// used more than once on the same variable and you can also create some custom +/// used more than once on the same variable, and you can also create some custom /// exclusion rules with the `#[exclude("regex")]` attributes that filter out all /// paths that verify the regular expression. /// -/// Sometime is useful to have tests file in a workspace folder to share them between the +/// Sometime is useful to have test files in a workspace folder to share them between the /// crates in your workspace. You can do that by use the usual parent folders `..` in /// the glob path. In this case the test names will be the relative path from the crate root -/// where the parent folder are replaced by `_UP`: for instance if you have a `valid_call.yaml` -/// in the folder `../test_cases` (from your crate) a test name could be +/// where the parent folder components are replaced by `_UP`: for instance if you have a +/// `valid_call.yaml` in the folder `../test_cases` (from your crate root) a test name could be /// `path_1__UP_test_cases_valid_call_yaml`. /// /// ## Use Parametrize definition in more tests @@ -706,7 +706,7 @@ pub fn fixture( /// } /// ``` /// -/// See [`rstest_reuse`](https://crates.io/crates/rstest_reuse) for more dettails. +/// See [`rstest_reuse`](https://crates.io/crates/rstest_reuse) for more details. /// /// ## Async /// @@ -811,9 +811,9 @@ pub fn fixture( /// In this case test pass because the delay is just 10 milliseconds and timeout is /// 80 milliseconds. /// -/// You can use `timeout` attribute like any other attibute in your tests and you can +/// You can use `timeout` attribute like any other attribute in your tests, and you can /// override a group timeout with a test specific one. In the follow example we have -/// 3 tests where first and third use 100 millis but the second one use 10 millis. +/// 3 tests where first and third use 100 milliseconds but the second one use 10 milliseconds. /// Another valuable point in this example is to use an expression to compute the /// duration. /// @@ -895,9 +895,9 @@ pub fn fixture( /// } /// /// #[rstest] -/// #[case::authed_user(alice())] // We can use `fixture` also as standard function +/// #[case::authorized_user(alice())] // We can use `fixture` also as standard function /// #[case::guest(User::Guest)] // We can give a name to every case : `guest` in this case -/// #[should_panic(expected = "Invalid query error")] // We whould test a panic +/// #[should_panic(expected = "Invalid query error")] // We would test a panic /// fn should_be_invalid_query_error( /// repository: impl Repository, /// #[case] user: User, @@ -970,7 +970,7 @@ pub fn fixture( /// /// `rstest` support also a syntax where all options and configuration can be write as /// `rstest` attribute arguments. This syntax is a little less verbose but make -/// composition harder: for istance try to add some cases to a `rstest_reuse` template +/// composition harder: for instance try to add some cases to a `rstest_reuse` template /// is really hard. /// /// So we'll continue to maintain the old syntax for a long time but we strongly encourage @@ -1061,7 +1061,7 @@ pub fn fixture( /// # fn is_valid(input: &str) -> bool { true } /// /// #[rstest( -/// input => ["Jhon", "alice", "My_Name", "Zigy_2001"] +/// input => ["John", "alice", "My_Name", "Zigy_2001"] /// )] /// fn should_be_valid(input: &str) { /// assert!(is_valid(input))