-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Allow message specification for should_fail #19560
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
Conversation
6e626a8
to
7d96b85
Compare
cc @steveklabnik - we talked about this on IRC yesterday. |
Interesting! This was somewhat surprising to me as I thought this would be a custom message to print out on test failure rather than "this test failed" with no output from the test. The semantic meaning implemented here, however, I think makes more sense to me. This is one of the major reasons I avoid |
Sure, changing |
The test harness will make sure that the panic message contains the specified string. This is useful to help make `#[should_fail]` tests a bit less brittle by decreasing the chance that the test isn't "accidentally" passing due to a panic occurring earlier than expected. The behavior is in some ways similar to JUnit's `expected` feature: `@Test(expected=NullPointerException.class)`. Without the message assertion, this test would pass even though it's not actually reaching the intended part of the code: ```rust #[test] #[should_fail(message = "out of bounds")] fn test_oob_array_access() { let idx: uint = from_str("13o").unwrap(); // oops, this will panic [1i32, 2, 3][idx]; } ```
7d96b85
to
6e5cc10
Compare
@alexcrichton updated. Also added a bit to the testing docs. |
6e5cc10
to
a20926a
Compare
The test harness will make sure that the panic message contains the specified string. This is useful to help make `#[should_fail]` tests a bit less brittle by decreasing the chance that the test isn't "accidentally" passing due to a panic occurring earlier than expected. The behavior is in some ways similar to JUnit's `expected` feature: `@Test(expected=NullPointerException.class)`. Without the message assertion, this test would pass even though it's not actually reaching the intended part of the code: ```rust #[test] #[should_fail(message = "out of bounds")] fn test_oob_array_access() { let idx: uint = from_str("13o").unwrap(); // oops, this will panic [1i32, 2, 3][idx]; } ```
The test harness will make sure that the panic message contains the
specified string. This is useful to help make
#[should_fail]
tests abit less brittle by decreasing the chance that the test isn't
"accidentally" passing due to a panic occurring earlier than expected.
The behavior is in some ways similar to JUnit's
expected
feature:@Test(expected=NullPointerException.class)
.Without the message assertion, this test would pass even though it's not
actually reaching the intended part of the code: