frondeus / test-case Goto Github PK
View Code? Open in Web Editor NEWRust procedural macro attribute for adding test cases easily
License: MIT License
Rust procedural macro attribute for adding test cases easily
License: MIT License
Thanks for the awesome crate!
I was wondering if there was any way to go about testing NaN
value equality? I've tried a few ideas to no success (unless I went about them wrong), such as using the hamcrest2
support.
If this isn't possible at the moment then I already have a workaround using regular tests, but maybe it could be supported somehow in the future.
Hi,
I am in a situation where my test case only must be compiled if some rust feature is enabled:
#[cfg(feature = "feature_type_a")]
#[test_case(TypeA)]
#[test_case(TypeB)]
fn do_stuff() {
...
}
The problem with the above code is that the cfg
is set for the entire function (all cases). If feature_type_a
is not enabled, the function do_stuff does not exist, but I want that it exists for TypeB
. Is there any way to pass a cfg
or a feature
into a test_case
? Something like: #[test_case(features = "feature_type_a", TypeA)]
Thank you so much!
I have been playing with pretty_assertions and really like it. But when trying to use it with test-case I seem to get errors of ambiguity over assert_eq
. Is it possible to use these two together?
error[E0659]: `assert_eq` is ambiguous (glob import vs any other name from outer scope during import/macro resolution)
--> src\squared\tests.rs:7:1
|
7 | #[test_case(5 => 25 ; "should be 25")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous name
|
= note: `assert_eq` could refer to a macro from prelude
note: `assert_eq` could also refer to the macro imported here
--> src\squared\tests.rs:7:1
|
7 | #[test_case(5 => 25 ; "should be 25")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: consider adding an explicit import of `assert_eq` to disambiguate
= help: or use `self::assert_eq` to refer to this macro unambiguously
warning: unused import: `test_case::test_case`
--> src\guessing_game\tests.rs:3:5
|
3 | use test_case::test_case;
| ^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
Here is the code. Uncommenting the pretty_assertions
line gives the error above. Without it, it runs normally.
#[allow(unused_imports)]
use crate::squared::squared;
//use pretty_assertions::assert_eq;
#[cfg(test)]
use test_case::test_case;
#[test_case(5 => 25 ; "should be 25")]
#[test_case(2 => 4 ; "should be 4")]
fn squared_test(num: i32) -> i32 {
squared(num)
Tests that were valid in 1.2.1 fail to compile with 1.2.2
an example can be seen here:
#[test_case("dtn:none" => "dtn:none" ; "when using none endpoint")]
#[test_case("dtn:n1/" => panics "" ; "when using dtn endpoint without double slash")]
#[test_case("dtn:none" => EndpointID::none().to_string() ; "when providing node eid and constructed none")]
fn from_str_tests(input_str: &str) -> String {
EndpointID::try_from(input_str).unwrap().to_string()
}
The compiler gives the following error:
error: Test function from_str_tests has a return-type but no exected clause in the test-case. This is currently unsupported. See test-case documentation for more details.
--> src/eid.rs:507:43
|
507 | fn from_str_tests(input_str: &str) -> String {
| ^^^^^^
Also, there seems to be a typo in the error message as exected
should probably be expected
.
Did the syntax change?
The changelog does not document any breaking changes regarding this.
I will be borrowing the example from #19, since it has some relation to how I found this error on my own code.
So, we know from that issue that the minus will be abstracted from the automatic name creation process, BUT, we have a mechanism for custom names, and that could help the developer to understand that the problem with his code is that he is lacking a valid test name:
#[test_case(15, 15; "Abs_15_15")]
#[test_case(-15, 15; "Abs_-15_-15")]
fn test_crazy_stuff(value: i32, expected: i32) {
assert_eq!(value.abs(), expected)
}
And this will raise a familiar error, but the interesting part is that it tried to use my custom name, since it begins with abs
, and not test_crazy_stuff
:
error[E0428]: the name `abs_15_15` is defined multiple times
--> src/lib.rs:162:5
|
162 | #[test_case(15, 15; "Abs_15_15")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| `abs_15_15` redefined here
| previous definition of the value `abs_15_15` here
This leads me to believe that we have a process that tries to make the name valid, since it erased the hyphen from my custom test, applied, and then we had a name collision.
I haven't tried to analyze the code to understand how the hyphen is erased in both cases, but, i believe that if a developer instantiates a custom name, it shouldn't be safeguarded, if the name is invalid it should break catastrophically warning the developer of what the problem is.
Clippy raises a warning to the following code.
#[cfg(test)]
mod tests {
use test_case::test_case;
#[test_case(1, 1)]
fn square(x: i32, y: i32) {
assert_eq!(x*x, y);
}
}
Messages from clippy,
warning: unneeded unit expression
--> src/main.rs:9:5
|
9 | #[test_case(1, 1)]
| ^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(clippy::unused_unit)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unused_unit
= note: this warning originates in the attribute macro `test_case` (in Nightly builds, run with -Z macro-backtrace for more info)
warning: 1 warning emitted
I think this warning should be suppressed in macro, or we should modify the macro not to use unit expressions, if possible.
how should one handle float comparisons with this library?
eg.
#[test_case(0 => 0.0)]
fn get_floatvalue: u128) -> f64 {
...
}
clippy output-
strict comparison of `f32` or `f64`
`#[warn(clippy::float_cmp)]` implied by `#[warn(clippy::pedantic)]`
`f32::EPSILON` and `f64::EPSILON` are available for the `error_margin`
for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#float_cmp
Are there any way to combine test_case with other attributes which can be applied to test functions e.g. serial_test?
I cannot compile the following example at v1.0.0 (and serial_test = "0.5.1"),
#[test_case(1)]
#[test_case(2)]
#[serial_test::serial]
fn need_to_be_serial(x: i32) {
assert!(x > 0);
}
Since Rust 1.61.0 the argument to an ignore
attribute has been printed as part of the test output. So:
#[test]
#[ignore = "Some reason"]
fn something() {...}
Will result in:
$ cargo test
...
test something ... ignored, Some reason
I believe the syntax has been valid for some releases prior to 1.61.0 (I'm afraid I don't know since when) but was ignored.
It would be great if test_case's ignore
modifier (and inconclusive
I suppose) could similarly take an option reason and propagate it so that cargo test
will show it.
I'm not sure that #[test_case(INPUT => ignore = "Some reason" OUTPUT)]
will fit the current syntax but perhaps #[test_case(INPUT => ignore("Some reason") OUTPUT)]
could work?
As an user of test case I want to be able to test whether actual
value is empty within complex assertions, eg.:
#[test_case("1" => is empty)] // fails
#[test_case("" => is empty)] // succeeds
fn test_this(s: &str) -> &str {
s
}
We can rely on #expr.is_empty()
and that user supplies a type that has such function.
Currently it doesn't seem to work:
#[tokio::test]
async fn test_case(name: &str) {
}
Output:
error: the test function cannot accept arguments
--> iml-services/iml-devices/src/db.rs:578:24
|
578 | async fn test_case(name: &str) {
| ^^^^^^^^^^
Is there a way to provide a test_case::test_case_tokio
macro to support async tests?
As an user of test case I want to be able to test whether actual
value matches giver regular expression within complex assertions, eg.:
#[test_case("1" => it matches_regex "[0-9]")]
fn test_this(s: &str) -> &str {
s
}
This feature has to be hidden behind feature flag (regex
) and require user to manually import https://docs.rs/regex/latest/regex/ crate
Is there a way to declare test cases only once and use them multiple times across multiple functions in multiple files? I read the wiki but I didn't see anything like that. If there isn't, that might be a feature worth adding.
Currently test_case
allows replacing it's built in assert
via using
and with
keywords.
We'd like to be able to replace assertion on per-function and global levels. This refers to requirements specified within #31.
Initial work specifies
#[test_case(input2)]
#[test_case_use(assert_nan)]
fn tested(v: X) -> f64 {
...
}
as possible solution for per-function replacements.
Part of #31.
Needs research.
custom_test_frameworks
feature could be a solution, but it's still unstable - using it is not an option (although it would immediately solve our problems in type safe manner).
#[test_case(SimpleEnum::Var1 => matches Ok(e) if e == SimpleEnum::Var1)]
#[test_case(SimpleEnum::Var2 => matches Err(e) if e == "var2")]
fn extended_pattern_matching_result(e: SimpleEnum) -> Result<SimpleEnum, &'static str> {
if e == SimpleEnum::Var1 {
Ok(e)
} else {
Err("var2")
}
}
outputs
Compiling basic v0.1.0 (/home/luke-biel/Workspace/frondeus/test-case/acceptance_tests/basic)
error: unexpected token
--> src/lib.rs:153:51
|
153 | #[test_case(SimpleEnum::Var1 => matches Ok(e) if e == SimpleEnum::Var1)]
| ^^
error: could not compile `basic` due to previous error
I would expect this to compile as per our wiki.
Hello,
i tried to use test-case
with test-env-log
but i got the error
error[E0659]:
test
is ambiguous (glob import vs any other name from outer scope during import/macro resolution)
use test_case::test_case;
use test_env_log::test;
#[test_case(4, 2 ; "when operands are swapped")]
#[test_case(-2, -4 ; "when both operands are negative")]
#[test_case(2, 4 ; "when both operands are positive")]
fn multiplication_tests(x: i8, y: i8) {
let actual = (x * y).abs();
assert_eq!(8, actual)
}
cargo test
Compiling git-gamble v2.1.1-alpha.0 (/home/pinage404/Project/git-gamble)
error[E0659]: `test` is ambiguous (glob import vs any other name from outer scope during import/macro resolution)
--> tests/test_env_log_with_test_case.rs:4:1
|
4 | #[test_case(4, 2 ; "when operands are swapped")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous name
|
note: `test` could refer to the attribute macro imported here
--> tests/test_env_log_with_test_case.rs:4:1
|
4 | #[test_case(4, 2 ; "when operands are swapped")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: consider adding an explicit import of `test` to disambiguate
= help: or use `self::test` to refer to this attribute macro unambiguously
note: `test` could also refer to the attribute macro defined here
--> /media/exec_downloaded/rust/rustup/toolchains/1.55.0-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:119:13
|
119 | pub use super::v1::*;
| ^^^^^^^^^^^^
= note: this error originates in the attribute macro `test_case` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0659`.
error: could not compile `git-gamble` due to previous error
How to use with test-env-log
?
related d-e-s-o/test-log#18
maybe related #38
Is it possible to generate a test-case per file in a directory? I'm working on an image generating program, and we have test images and it would be convenient to be able to say something like:
#[test_resources("images/*")]
fn image_test(path: &Path) {
// image test code
}
This is possible with test-generator but it's less actively maintained.
I'm not sure if I'm the only one asking for this, but this feels like a no brainer, so it's kind of curious...
I want to use #[test_case]
annotations on functions that are not test functions but the actual functions that implement things. They might be a part of the public API, or just used by many other functions in the same file. This would be similar to writing a "doc test", but a doc test is necessarily 3 lines and quite verbose compared to just a test_case annotation. Additionally, doc tests are not part of the normal unit test frameworks, but instead handled with a special binary, which causes all sorts of annoyance.
Currently, just adding the annotation causes there to be a module added with the function name, and the function to be moved inside that module, and then followed by all the generated test case functions. Instead, I would want the module to be named test_<ident>
, the generated test cases placed inside that and the function to be left exactly as is. To be honest, that's how I assumed this to work.
This would probably need to be a flag, or a separate macro, since I guess all the current users assume that the test case function is purely for testing.
JUnit
has a really nice feature where, given an enum, you can make a test that will generate an instance of the test for each member of the enum. For instance, you could have something like this
public enum Player {
PLAYER1, PLAYER2;
}
@ParameterizedTest
@EnumSource(Player.class)
void initializingTheGameStartsWithTheGivenPlayer(Player initialPlayer) {
// ...
}
It would be cool if you could do something like this with test_case
enum Player {
Player1,
Player2,
}
#[test_case(Player)]
fn test_for_each_player(player: Player) {
// ...
}
Now, obviously this wouldn't work if the enum had values attached to any of the variants, but at least for this specific case, it prevents you from forgetting to add a test case when you add an enum variant (since it would be auto-generated)
There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.
Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.
Example code
#[test_case(vec![(1,1),(2,2),(3,3)].iter().collect(), vec![(1,1),(2,2),(3,3)].iter().collect() ; "test")]
fn get_changes_values<
'a,
'b,
K: Eq + Ord + Clone + fmt::Debug,
V: Eq + fmt::Debug,
>(
old: &'b BTreeMap<&'a K, V>,
new: &'b BTreeMap<&'a K, V>,
) {
let changes = super::get_changes_values(old, new);
// test_case => "test"
assert_debug_snapshot(test_case, changes);
}
I forgot about it - recently I merged PR with README (#27) - but this README.md will be overwritten during the next release.
Therefore I have to move all changes made there into lib.rs
as I use cargo readme
.
#[test_case(1 => panics)]
fn foo(_x: u32) {
panic!(":(");
}
right now, only
#[test_case(1 => panics "")]
fn foo(_x: u32) {
panic!(":(");
}
is supported
As in title. Since we support using test case on free floating fn
items, it would be useful to review if we can enable this functionality on impl
blocks, eg.:
impl StructName {
#[test_case("abcd" => Ok(("ab", "cd")))]
fn parse(input: &[u8]) -> IResult<&[u8], &[u8])> {
todo!()
}
}
this may require extra attribute though.
In Rust 2018 test can return a Result
type, with Result::Err
being interpreted as a failure. However with parameterised tests returned errors are treated as passing. While this can be fixed by specifying an expected value, it is unintuitive.
Example:
fn should_equal_4(num: i32) -> Result<(), ()> {
if num == 4 {
Ok(())
} else {
Err(())
}
}
#[cfg(test)]
mod tests {
use super::*;
use test_case::test_case;
#[test_case(4; "Passing")]
#[test_case(5; "Failing")]
fn with_params(num: i32) -> Result<(), ()> {
should_equal_4(num)?;
Ok(())
}
#[test]
fn is_4() -> Result<(), ()> {
should_equal_4(4)?;
Ok(())
}
#[test]
fn is_5() -> Result<(), ()> {
should_equal_4(5)?;
Ok(())
}
}
Expected: Both tests::with_params::failing()
and is_5()
fail.
Actual: Only is_5()
fails.
When using => expected
syntax it could be nice to set up what assertion shall we use.
It might be extra attribute:
#[test_case("foo" => "bar")]
#[test_case_assert_macro(assert_diff)]
fn test(input: &str) -> String { input.to_string() }
this could be expanded into:
mod test {
use super::*;
fn test(input: &str) -> String { input.to_string() }
#[test]
fn foo_expects_bar() {
let actual = test("foo");
assert_diff!("bar", actual);
}
Right now test-case
do not support impl Trait
in function arguments:
#[test_case("foo")]
fn test_foo(foo: impl Into<String>) { }
It returns error:
error[E0562]:
impl Trait
not allowed outside of function and inherent method return types
|
301 | fn test_foo(foo: impl Into) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: add #![feature(impl_trait_in_bindings)] to the rate attributes to enable
When I use the latest
test-case
andtest-log
(new name oftest-env-log
) together, I get duplicate copies of each test generated.
I also tried it with what I think were the versions from when this issue was created and have the same problem.
#[cfg(test)]
mod tests {
use test_case::test_case;
#[test_case(0, 0 ; "the same")]
#[test_case(0, 1 ; "different")]
#[test_log::test]
// #[test_env_log::test]
fn equality(a: usize, b: usize) {
log::info!("a: {}", a);
log::info!("b: {}", b);
assert_eq!(a, b)
}
}
running 4 tests
test tests::equality::the_same ... ok
test tests::equality::the_same ... ok
test tests::equality::different ... FAILED
test tests::equality::different ... FAILED
failures:
---- tests::equality::different stdout ----
thread 'tests::equality::different' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `1`', main.rs:18:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- tests::equality::different stdout ----
thread 'tests::equality::different' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `1`', main.rs:18:9
failures:
tests::equality::different
tests::equality::different
test result: FAILED. 2 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
error: test failed, to rerun pass '--bin main'
Originally posted by @newsch in #69 (comment)
The README has the following example for the base usage:
#![cfg(test)]
extern crate test_case;
use test_case::test_case;
#[test_case( 2, 4 ; "when both operands are possitive")]
#[test_case( 4, 2 ; "when operands are swapped")]
#[test_case(-2, -4 ; "when both operands are negative")]
fn multiplication_tests(x: i8, y: i8) {
let actual = (x * y).abs();
assert_eq!(8, actual)
}
However, I cannot get this to work. I get the following error:
error: an inner attribute is not permitted in this context
--> src/bin/second.rs:246:3
|
246 | #![cfg(test)]
| ^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
When I take out the !
, things work better, but not quite yet. When building regular (not test) the extern
and use
lines trigger errors. These go away when I do the following:
#[cfg(test)]
mod tests {
extern crate test_case;
use test_case::test_case;
#[test_case( 2, 4 ; "when both operands are possitive")]
#[test_case( 4, 2 ; "when operands are swapped")]
#[test_case(-2, -4 ; "when both operands are negative")]
fn multiplication_tests(x: i8, y: i8) {
let actual = (x * y).abs();
assert_eq!(8, actual)
}
}
Am I doing things wrong?
I don't know if this matches the plan for the crate but I though it is suitable.
The QA in the project I work on have a csv
file with test cases input/output:
scenario_name,assert_http_code,assert_error_message,name
May not have linebreaks,400,error message,\n
...
I wanted to use it to generate test cases in rust, I was thinking about something like:
#[test_input] // used to generate test names
struct TestInput {
scenario_name: String,
assert_http_code: u16,
assert_error_message: String,
name: String,
}
#[generate_test_suite_from_file("path_to_file.csv")] // parsed by https://crates.io/crates/csv
fn test_suite_name(input: TestInput) {
// ... test code
}
This would generate:
mod test_suite_name {
#[test]
fn may_not_have_linebreaks(input: TestInput) {
// ... test code
}
}
Existence of hamcrest_assertions
is usefull, but requires addition of an extra crate. It would be beneficial if user could write test_case(args => is ...)
without extra work.
For first release, for all assertions provided by hamcrest2
lib we should either cover it with our own syntax or mention replacement/why it's not implemented.
Later we'll be able to expand functionality of is|it
on our own.
eq
- already covered via arg => value
is equal_to Xeq
lt
is less_than Xleq
is less_or_equal_than Xgt
is greater_than Xgeq
is greater_or_equal_than Xtype_of
- do we need that?close_to
is almost_equal_to Xpath_exists
is existing_pathfile_exists
is filedir_exists
is dirmatches Ok(5)
can be usedhas
- matches Ok(v) if v != 5
ok
- matches Ok(_)
& matches Err(_)
err
- samesome
- samenone
- samecontains
it contains Xcontains_exactly
- matches vec![1, 2, 3]
& matches [1, 2, 3]
contains_in_order
it contains_in_order [X, Y, Z]all
any
is(bool)
- supported via arg => value
anything
- useless in test_case
contextE.g. this works
#[test_case(0 => ignore 0)]
fn foo(x: u8) -> u8 {
42
}
This doesn't
#[test_case(0 => ignore)]
fn bar(x: u8) {
}
Example output:
running 2 tests
test tests::foo::_0_expects_inconclusive0 ... ignored
test tests::bar::_0_expects ... ok
test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.00s
Version: 2.0.2
I'm using test_case in my prod code (outside of #[cfg(test)]
)
#[test_case(br#""abc""#, Ok(b"", TokenUnicodeString("abc".to_string())))]
fn parse_token_unicode_string<'a>(input: &'a [u8]) -> Result<(&'a [u8], TokenUnicodeString), Error> {
returns
error[E0261]: use of undeclared lifetime name `'a`
--> crates/kami-schema/src/unicode_string.rs:11:64
|
11 | fn parse_token_unicode_string<'a>(input: &'a [u8]) -> Result<(&'a [u8], TokenUnicodeString), Error> {
| ^^ undeclared lifetime
and for
#[test_case(br#""abc""#, Ok(b"", TokenUnicodeString("abc".to_string())))]
fn parse_token_unicode_string(input: &[u8]) -> Result<(&[u8], TokenUnicodeString), Error> {
it prints out
error[E0106]: missing lifetime specifier
--> crates/kami-schema/src/unicode_string.rs:11:56
|
11 | fn parse_token_unicode_string(input: &[u8]) -> Result<(&[u8], TokenUnicodeString), Error> {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime
|
11 | fn parse_token_unicode_string(input: &[u8]) -> Result<(&'static [u8], TokenUnicodeString), Error> {
| ~~~~~~~~
Without test_case()
attribute it compiles. I'd expect this to work after changes made in 2.0
.
/u/somebodddy noticed that inconclusive
could be keyword, not a part of string.
#[ignore]
attribute.inconclusive
, tommorow could be should_panic
.#[ignore]
attribute (which may cause failed tests or false positives or even non deterministic CI behavior)Feel free to comment :)
I noticed that commits have been made to fix the issue with syn 1.0.58. Will a 1.0.1 be released soon to address this?
Thanks.
It could be nice to rewrite or extend docs to be clear and informative - how to use this library with all features.
clippy complains if the return value is a boolean, since this results in a assert_eq!(expected_bool, actual_bool)
, which clippy was rather a assert!(actual_bool)
or assert!(!actual_bool)
workaround is to add a #[allow(clippy::bool_assert_comparison)]
to the test attributes. I think test-case
should do that internally
#[test_case()]
fn should_work() {}
#[test_case( ; "name")]
fn should_definitely_work() {}
How to generate test case name if there are no arguments.
As an user of test case I want to be able to test for lenght of actual
value within complex assertions, eg.:
#[test_case(b"1" => is len 1)]
fn test_this(s: &[u8]) -> &[u8] {
s
}
This feature can use simple #expr
.len() and assume user uses type that supplies len
method
It seems that test-case able to handle generic parameters, i.e.:
#[test_case(1i8; "xyz")]
fn my_test<T>(x: T)
where T: Debug
{
println!("{:?}", x);
}
but is it possible to specify a type parameter explicitly? That's in particular useful for cases, where you need to check conversion for specific trait, e.g.:
#[test_case(MyType { .. }; "xyz")]
fn my_test<T>(x: MyType)
where T: From<MyType>
{
let _: T = x.into();
}
pinning to 1.0.57 should fix, or updating the import from export
to __private
.
Example error in github actions:
error[E0432]: unresolved import `syn::export`
--> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/test-case-1.0.0/src/test_case.rs:3:10
|
3 | use syn::export::TokenStream2;
| ^^^^^^ could not find `export` in `syn`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `test-case`
I tried raising on syn but it looks like @dtolnay has made raising issues there restricted to contributors. This feels like it shouldn't have been a patch release?
This is a tracking issue for test_case
roadmap beyond 1.x
.
Features are waiting to be implemented or are being currently implemented. 2.0.0
is coming with major codebase rewrite, thus it will be released as rc
first to test stability and portability from 1.x
versions.
# 2.0.0
inconclusive
within description (currently deprecated)hamcrest_assertions
in favor of custom solution #75#[test_case(args => with |x: T| assert!(...))]
for inline custom assertions #31#[test_case(args => using $path)]
for custom assertion reuse #31#[test_case]
with no return type matching support Result<(), E> where E: Error
similar to #[test]
macro #50test_cases
via #[test_case_handler($path)]
attribute #83#[test_case(args as function_name)]
, #[test_case(args => result as function_name)]
and #[test_case(args => result ; "description" as function_name)]
#72with |val: T| -> bool {body}
is allowed without assertion
within bodytest_case
block #37test_case
could look after custom_test_frameworks
are stabilized: https://github.com/luke-biel/interrogateFor:
#[test_case(15, 15)]
#[test_case(-15, 15)]
fn test_abs(value: f64, expected: f64) {
assert_eq!(value.abs(), expected)
}
We get error:
error[E0428]: the name
_15_15
is defined multiple times
--> src/test.rs
|
| #[test_case(15, 15)]
| ^^^^^^^^^^^^^^^^^^^^
| |
| previous definition of the value_15_15
here
|_15_15
redefined here
|
= note:_15_15
must be defined only once in the value namespace of this mod
Pattern matching assertions should definitely be a thing.
Can it do things like #[test_case(Some(3) => Some(_))] ?
Comment made by /u/gilescope
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.