rust/tests/ui/test-attrs/test-should-fail-good-message.rs

// run-pass
// needs-unwind
// compile-flags: --test
#[test]
#[should_panic(expected = "foo")]
pub fn test_foo() {
    panic!("foo bar")
}

#[test]
#[should_panic(expected = "foo")]
pub fn test_foo_dynamic() {
    panic!("{} bar", "foo")
}
tests: Add missing run-pass annotations 2019-07-26 16:54:25 -05:00			`// run-pass`
Add needs-unwind to tests that depend on panicking This directive isn't automatically set by compiletest or x.py, but can be turned on manually for targets that require it. 2021-12-03 09:32:51 -06:00			`// needs-unwind`
Allow message specification for should_fail 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]; } ``` 2014-12-05 01:02:36 -06:00			`// compile-flags: --test`
			`#[test]`
Rename #[should_fail] to #[should_panic] 2015-01-31 17:08:25 -06:00			`#[should_panic(expected = "foo")]`
Fallout in testing. 2015-03-15 15:00:41 -05:00			`pub fn test_foo() {`
Allow message specification for should_fail 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]; } ``` 2014-12-05 01:02:36 -06:00			`panic!("foo bar")`
			`}`

			`#[test]`
Rename #[should_fail] to #[should_panic] 2015-01-31 17:08:25 -06:00			`#[should_panic(expected = "foo")]`
Fallout in testing. 2015-03-15 15:00:41 -05:00			`pub fn test_foo_dynamic() {`
Allow message specification for should_fail 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]; } ``` 2014-12-05 01:02:36 -06:00			`panic!("{} bar", "foo")`
			`}`