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-27 00:54:25 +03: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 15:32:51 +00: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-04 23:02:36 -08:00			`//@ compile-flags: --test`
			`#[test]`
Rename #[should_fail] to #[should_panic] 2015-01-31 15:08:25 -08:00			`#[should_panic(expected = "foo")]`
Fallout in testing. 2015-03-16 09:00:41 +13: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-04 23:02:36 -08:00			`panic!("foo bar")`
			`}`

			`#[test]`
Rename #[should_fail] to #[should_panic] 2015-01-31 15:08:25 -08:00			`#[should_panic(expected = "foo")]`
Fallout in testing. 2015-03-16 09:00:41 +13: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-04 23:02:36 -08:00			`panic!("{} bar", "foo")`
			`}`