You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fnouter(x:i32) -> i32{fninner(a:i32,b:i32) -> i32{
a + b
}#[test]fntest_inner(){assert_eq!(inner(3,5),8);}inner(x,5)}#[test]fntest_outer(){assert_eq!(outer(3),8);}
Reacted by Guillaume E, Josh Berry, EFanZh, Chris Wong, Luke, shikoku1, Demiu, Evgeny and Shane F. Carr
But why though ? Do you want to be able to test things inner to your function ? How about an assert_test! that would compile / trigger only when in test mode ? Just an idea.
I'm just arguing against my own idea here, but that would require either :
Require to recompile everything related for "test", which I don't know which is a good idea or not
Compile this only in debug mode, but only run it when doing test (so it's still in the binary but there is a conditional for whether or not this is in test mode)
My code is horrible so it doesn't have that much tests, is it possible to run tests in release mode ? If that is the case, the second option is a no-no I guess.
I would like this in order for a macro to be able to generate tests without having to come up with a name for the tests.
Example: something like
macro_rules! tested_varule {($type:path, $bytes:expr) => {{constBYTES:&[u8] = $bytes;
#[test]fn test_tested_varule(){use $crate::ule::VarULE;
assert!(<$type>::validate_bytes(BYTES).is_ok());}// Safety: If the above test passes, then these are valid bytesunsafe{&*(BYTESas*const[u8]as*const $type)}}};}constMY_STR_1:&str = tested_varule!(str,&[0x61,0x62,0x63]);
Activity
Cobrand commentedon Sep 21, 2016
But why though ? Do you want to be able to test things inner to your function ? How about an assert_test! that would compile / trigger only when in test mode ? Just an idea.
kineticz commentedon Sep 21, 2016
Because this is convenient for testing nested functions. Currently I'd have to move the fn outside to be able to test it separately.
kineticz commentedon Sep 21, 2016
@Cobrand Yeah, something like this will be great:
Cobrand commentedon Sep 21, 2016
I'm just arguing against my own idea here, but that would require either :
My code is horrible so it doesn't have that much tests, is it possible to run tests in release mode ? If that is the case, the second option is a no-no I guess.
Aatch commentedon Sep 22, 2016
The problem with this is that the test harness needs to access the inner functions, which it can't do because you can't name them.
Mark-Simulacrum commentedon May 13, 2017
I'm marking as a diagnostics issue so that we print a warning in this case at least.
[-]Test attribute inside an fn[/-][+]Inner function cannot be tested[/+]Auto merge of #51450 - estebank:inner-fn-test, r=@pnkfelix
eddyb commentedon Jul 13, 2018
Why was the #51450 PR accepted, while the RFC is still unmerged?
I disagree with the approach taken (a new lint), we should either (rust-lang/rfcs#2471 (comment)):
unused_attributeisn't firing, and let that handle the lint side#[test]functions anywhere, as per Add lint warning for inner function marked as#[test]rfcs#2471 (comment)PaulDotSH commentedon Jun 12, 2022
Auto merge of rust-lang#114414 - cjgillot:early-unnameable-test, r=pe…
Auto merge of #114414 - cjgillot:early-unnameable-test, r=petrochenkov
sffc commentedon Apr 25, 2026
I would like this in order for a macro to be able to generate tests without having to come up with a name for the tests.
Example: something like