4 ms·
> Test generation > Data driven tests are an easy way to cover a lot of cases (granted, property testing is even better). The most trivial way of doing this is
by codetrotter 3y ago
> Test generation
> Data driven tests are an easy way to cover a lot of cases (granted, property testing is even better). The most trivial way of doing this is just looping over your cases
> […]
> You don't know which input was being processed on failure (without extra steps)
> Any debug output from prior iterations will flood the display when analyzing a failure
For generating separate tests for different inputs, keeping it easy to see which input failed the test I use the test-case crate
https://crates.io/crates/test-case https://crates.io/crates/test-case
Here’s an example from the test-case readme:
#[cfg(test)]
mod tests {
use test_case::test_case;
#[test_case(-2, -4 ; "when both operands are negative")]
#[test_case(2, 4 ; "when both operands are positive")]
#[test_case(4, 2 ; "when operands are swapped")]
fn multiplication_tests(x: i8, y: i8) {
let actual = (x * y).abs();
assert_eq!(8, actual)
}
}
And then when you run
cargo test
You get this output:
running 3 tests
test tests::multiplication_tests::when_both_operands_are_negative ... ok
test tests::multiplication_tests::when_both_operands_are_positive ... ok
test tests::multiplication_tests::when_operands_are_swapped ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
- keyle 3y agoThis is so cool, I haven't seen this ... Python I think? The doctest I think it was called. But at compile time without static analysis tools, this is so cool.
- formerly_proven 3y ago> This is so cool, I haven't seen this ... Python I think? The doctest I think it was called. @pytest.mark.parametrize https://docs.pytest.org/en/7.2.x/how-to/parametrize.html#pytest-mark-parametrize-parametrizing-test-functions https://docs.pytest.org/en/7.2.x/how-to/parametrize.html#pyt...
- lozenge 3y agoYou can use subTest in Python, and there are packages which provide parameterize for unittest as well. https://docs.python.org/3/library/unittest.html#subtests https://docs.python.org/3/library/unittest.html#subtests
- mqus 3y agoThis is pretty good, but since it's static, you can't use parameter generating methods (e.g. for combinatorial input or derived tests). And if you do that within the test, you're back to having to manage those on your own. JUnit&AssertJ really do have advantages on Rust here.
- vladvasiliu 3y agoIs proptest something that could handle this? https://github.com/proptest-rs/proptest https://github.com/proptest-rs/proptest
- PartiallyTyped 3y agoMaybe https://github.com/BurntSushi/quickcheck https://github.com/BurntSushi/quickcheck too?
- Ygg2 3y agoI do like C# test casing better where you take n+1 params. N being n params in function, and return value being the expected value. Very clean #[test_case(-2, -4, 8 ; "when both operands are negative")] #[test_case(2, 4, 8 ; "when both operands are positive")] #[test_case(4, -2, 8 ; "when one operands is negative")] fn multiplication_tests(x: i8, y: i8) -> i8 { x * y }
- epage 3y agoI think I bring up rstest at some point which supports similar. The downside is it is static. For example, I can't discover tests from the filesystem like trybuild does.
- nicoburns 3y agoIt’s also very slow to build