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
In order to test the error behaviour of a function you need an error struct to compare with. For example:
since ParseIntError is private, I have to generate one by doing something wrong, like u8::from_str("257"). This leads to the following test:
let pie_overflow = u8::from_str("257").unwrap_err();assert_eq!(Missions::parse_enc_opt("ascii,256,U+41..U+67",8).unwrap_err(), pie_overflow);
If error types where public I would rather instantiate one and write:
let pie_overflow = ParseIntError{kind: std::num::Overflow};assert_eq!(Missions::parse_enc_opt("ascii,256,U+41..U+67",8).unwrap_err(), pie_overflow);
Let's come up with a guideline that empowers library consumers to test failure cases conveniently.
The text was updated successfully, but these errors were encountered:
I feel like this is too diverse of a problem to address with a guideline. It is also not much of a backward compatibility risk -- if a crate is stabilized with untestable errors, exposing a way to test them will typically be additive. I would let crate authors figure this out case by case.
From rust-lang/rust#39381.
In order to test the error behaviour of a function you need an error struct to compare with. For example:
since
ParseIntError
is private, I have to generate one by doing something wrong, likeu8::from_str("257")
. This leads to the following test:If error types where public I would rather instantiate one and write:
Let's come up with a guideline that empowers library consumers to test failure cases conveniently.
The text was updated successfully, but these errors were encountered: