Use just `[rstest]` to generate test.

[svenstaro]

My macro knowledge is pretty poor so please excuse my ignorance, but I think it'd be conceptually and syntactically to use have [rstest] which may also be optionally parametrized. What do you think?

[la10736]

Should work... maybe I can just remove rstest_parametrize() case and fall back in standard case if no cases provided.

Ok, I'll do some tests. If I don't find any problem I'll deprecate rstest_parametrize() in the next release (0.4.0) and then remove it in 0.5.0.

[la10736]

By [rstest] we can cover all cases:

• simple identity like name means I should give it in case()
• identity => [v1,.., vn] like name => [1,2,3] means matrix arguments
• no referenced identity resolved by fixture search

For instance in the same test you can have a parameter from list and other 2 from cases: in this case will run all cases for each value in list.

[KSXGitHub]

I don't think => for matrix would not be clear enough. My suggestion is to use matrix for matrix in combination of case for individual cases.

This following snippet

#[rstest(
  params(foo, bar),
  matrix(
    foo => [0, 1, 2],
    bar => ['a', 'b'],
  ),
  case(8, 'f'),
)]
fn mytest(foo: i32, bar: char) {}

should be equivalent to

#[rstest_parametrize(
  foo, bar,
  case(0, 'a'),
  case(1, 'a'),
  case(2, 'a'),
  case(0, 'b'),
  case(1, 'b'),
  case(2, 'b'),
  case(8, 'f'),
)]
fn mytest(foo: i32, bar: char) {}

I not sure if this syntax is good enough.

[la10736]

Ok, I'll think about this even if my idea is that in test writing you should remove all boilerplate that you can even if the syntax become less explicit.

[KSXGitHub]

you should remove all boilerplate that you can even if the syntax become less explicit.

Rustfmt has a problem with current rstest_parametrize: cargo fmt will turn the following code

#[rstest_parametrize(
  foo, bar, baz,
  case(0, 'a', 'A'),
  case(1, 'b', 'B'),
)
fn mytest (foo: u32, baz: char, baz: char) {}

into this

#[rstest_parametrize(
  foo,
  bar,
  baz,
  case(0, 'a', 'A'),
  case(1, 'b', 'B'),
)
fn mytest (foo: u32, baz: char, baz: char) {}

This is why I think params() (or a pair of parenthesis at the very least) is necessary.

[la10736]

Hi @KSXGitHub, I don't think that how rustfmt works on rstest_parametrize is a good argumentto choose the syntax. Anyway the behavior that you describe depends on rustfmt configurations:

on my machine use rustfmt without any configuration change it in

#[rstest_parametrize(foo, bar, baz, case(0, 'a', 'A'), case(1, 'b', 'B'))]
fn mytest(foo: u32, bar: char, baz: char) {}

Anyway what we are doing here is to build a new DSL and we cannot write DSL according to Attribute, Meta and NestedMeta rustfmt formatting choices. What we can do is to open a ticket (and maybe a pull request) to extend [rustfmt::skip::macros()] attribute to skip procedural macros too.

I took a look to rustfmt code and should be simple to implement it. In the meantime we can use #[rustfmt::skip] as workaround:

#[rustfmt::skip]
#[rstest_parametrize(
  foo, bar, baz,
  case(0, 'a', 'A'),
  case(1, 'b', 'B'),
)]
fn mytest (foo: u32, bar: char, baz: char) {}

Or use a small comment to do the trick

#[rstest_parametrize( // This prevent formatting
  foo, bar, baz,
  case(0, 'a', 'A'),
  case(1, 'b', 'B'),
)]
fn mytest (foo: u32, bar: char, baz: char) {}

[la10736]

Maybe by use rust-lang/rust#60406 we can improve the syntax a lot by move argument related data near the argument instead try to express it external attribute.

[la10736]

Just for the record: rust-lang/rustfmt#3665 will introduce rustfmt::skip::attributes() attribute both at item and module level. So we can use it to skip formatting in rstest's attribute. Unfortunately we can do it at rstest crate but should be the user that add this rustfmt directive to his code.

[la10736]

I'm staring to work on it (moved on 0.5 release)

TODO:

• integrate parametrize
  • first happy pathintegration test
  • parsing
  • rendedering (if some cases)
  • error if indicate some args but no cases
  • move all integration tests in rstest module
  • route parametrize to rstest
  • clean up tests
• integrate matrix
  • first happy path integration test
  • parsing
  • Add tests for parsing both matrix, cases and fixture
  • Remove matrix parse module and move ValueList in its own module
  • rendedering (if some cases)
  • move all integration tests in rstest module
  • route matrix to rstest
  • clean up tests
• cross cases
  • test happy path all together
  • implement logic for handling all cross cases
  • write unit tests for cross cases
  • refactor (wrap by module)
  • check tests about handling error (multiple cross args)
  • redirect rstest_parametrize and rstest_matrix docs to rstest
• Unsorted
  • Add literal unit test for Fixture