Skip to content

Testability of errors #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dtolnay opened this issue May 20, 2017 · 1 comment
Closed

Testability of errors #69

dtolnay opened this issue May 20, 2017 · 1 comment
Labels
new guideline A proposed new guideline

Comments

@dtolnay
Copy link
Member

dtolnay commented May 20, 2017

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, 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.

@dtolnay
Copy link
Member Author

dtolnay commented Oct 29, 2017

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.

@dtolnay dtolnay closed this as completed Oct 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new guideline A proposed new guideline
Projects
None yet
Development

No branches or pull requests

1 participant