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

// run-pass
// ignore-wasm32-bare compiled with panic=abort by default
// 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`
Re-enable Emscripten's exception handling support Passes LLVM codegen and Emscripten link-time flags for exception handling if and only if the panic strategy is `unwind`. Sets the default panic strategy for Emscripten targets to `unwind`. Re-enables tests that depend on unwinding support for Emscripten, including `should_panic` tests. 2019-10-18 16:47:54 -05:00			`// ignore-wasm32-bare compiled with panic=abort by default`
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")`
			`}`