Testing Panics and Returning `Result` from Tests

20 min read

Not every test is a simple “given input, assert output.” Sometimes the correct behavior is to fail loudly, and sometimes the test body itself is full of fallible steps. Rust gives you two dedicated tools for these cases: the #[should_panic] attribute and tests that return Result<(), E> so you can use the ? operator.

Quick Overview

In Jest or Vitest you assert that code throws with expect(fn).toThrow(...), and you write fallible test bodies as async functions that await and let rejections bubble up. Rust splits these into two distinct mechanisms: a test marked #[should_panic(expected = "...")] passes only if its body panics with a message containing the expected substring, and a test whose signature is -> Result<(), E> lets you use the ? operator so any Err cleanly fails the test instead of forcing a sea of .unwrap() calls. Knowing which to reach for is the difference between a test that documents a real invariant and one that quietly passes for the wrong reason.

TypeScript/JavaScript Example

In a Jest/Vitest suite, asserting that something throws and writing a fallible test body look like this:

1
export function withdraw(balance: number, amount: number): number {
2
  if (amount > balance) {
3
    throw new Error(
4
      `insufficient funds: balance is ${balance}, tried to withdraw ${amount}`,
5
    );
6
  }
7
  return balance - amount;
8
}
9

10
// banking.test.ts
11
import { describe, it, expect } from "vitest";
12
import { withdraw } from "./banking";
13

14
describe("withdraw", () => {
15
  // Asserting a throw. The matcher wraps the call in a try/catch for you.
16
  it("rejects overdrafts", () => {
17
    expect(() => withdraw(100, 150)).toThrow("insufficient funds");
18
  });
19

20
  it("succeeds within balance", () => {
21
    expect(withdraw(100, 30)).toBe(70);
22
  });
23

24
  // A fallible test body: the function is `async`, and any rejected promise
25
  // (or thrown error) automatically fails the test.
26
  it("loads and parses config", async () => {
27
    const raw = await readFile("config.json", "utf8"); // may reject
28
    const config = JSON.parse(raw); // may throw
29
    expect(config.port).toBe(8080);
30
  });
31
});

Two things are happening here. expect(() => ...).toThrow(...) passes the function (not its result) so the matcher can catch the throw itself, and it matches the error message as a substring. Separately, the async test body lets a rejected await or a thrown JSON.parse fail the test without any explicit error plumbing — the test runner treats a rejected promise as a failure.

Rust Equivalent

Rust expresses the first case with the #[should_panic] attribute and the second with a Result-returning test signature:

1
use std::num::ParseIntError;
2

3
/// Withdraw `amount` from `balance`, panicking if it would overdraw.
4
pub fn withdraw(balance: u32, amount: u32) -> u32 {
5
    if amount > balance {
6
        panic!("insufficient funds: balance is {balance}, tried to withdraw {amount}");
7
    }
8
    balance - amount
9
}
10

11
#[derive(Debug, PartialEq)]
12
pub struct Rgb {
13
    pub r: u8,
14
    pub g: u8,
15
    pub b: u8,
16
}
17

18
/// Parse a `#rrggbb` hex color string.
19
pub fn parse_hex_color(s: &str) -> Result<Rgb, ParseIntError> {
20
    let s = s.trim_start_matches('#');
21
    let r = u8::from_str_radix(&s[0..2], 16)?;
22
    let g = u8::from_str_radix(&s[2..4], 16)?;
23
    let b = u8::from_str_radix(&s[4..6], 16)?;
24
    Ok(Rgb { r, g, b })
25
}
26

27
#[cfg(test)]
28
mod tests {
29
    use super::*;
30

31
    // Asserting a panic, matching part of the message.
32
    #[test]
33
    #[should_panic(expected = "insufficient funds")]
34
    fn overdraw_panics() {
35
        withdraw(100, 150);
36
    }
37

38
    #[test]
39
    fn withdraw_succeeds() {
40
        assert_eq!(withdraw(100, 30), 70);
41
    }
42

43
    // A fallible test body: `?` propagates any `Err`, failing the test.
44
    #[test]
45
    fn parses_white() -> Result<(), ParseIntError> {
46
        let color = parse_hex_color("#ffffff")?;
47
        assert_eq!(color, Rgb { r: 255, g: 255, b: 255 });
48
        Ok(())
49
    }
50
}

Running cargo test produces:

1
running 3 tests
2
test tests::parses_white ... ok
3
test tests::withdraw_succeeds ... ok
4
test tests::overdraw_panics - should panic ... ok
5

6
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

The - should panic annotation in the runner output tells you the test was expected to panic and did. The ? in parses_white is the direct analog of await in an async Jest test: if parse_hex_color returns an Err, the ? returns it from the test function, and the runner marks the test failed.

Detailed Explanation

`#[should_panic]` inverts the pass/fail condition

A normal #[test] passes when its body runs to completion without panicking. Adding #[should_panic] inverts that contract: the test passes only if the body panics, and fails if it returns normally. The attribute is stacked below #[test]:

1
#[test]
2
#[should_panic]
3
fn overdraw_panics() {
4
    withdraw(100, 150); // must panic, or the test fails
5
}

This is the analog of Jest’s expect(fn).toThrow() with no argument — “I don’t care about the message, just that it throws.”

`expected` matches a substring, not the whole message

The bare #[should_panic] is blunt: it passes if the body panics for any reason at all, which is dangerous (see Common Pitfalls). Add expected = "..." to require that the panic message contains that substring:

1
#[test]
2
#[should_panic(expected = "insufficient funds")]
3
fn overdraw_panics() {
4
    withdraw(100, 150);
5
}

The check is a substring match (via str::contains), not an exact-equality or regex match — exactly like Jest’s toThrow("...") with a string argument. If the actual panic message does not contain the expected substring, the test fails and the runner prints both strings so you can see the mismatch. With our withdraw panicking on a "account frozen" expectation, the failure looks like this:

1
thread 'tests::wrong_expected_substring' panicked at src/lib.rs:3:9:
2
insufficient funds: balance is 100, tried to withdraw 150
3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
4
note: panic did not contain expected string
5
      panic message: "insufficient funds: balance is 100, tried to withdraw 150"
6
 expected substring: "account frozen"

Tip: Always prefer #[should_panic(expected = "...")] over the bare form. The expected string nails down why the code panicked, so the test cannot pass because of an unrelated panic (a typo’d array index, a different unwrap failing, and so on).

`#[should_panic]` catches any panic, including `assert!` and overflow

The body just needs to panic — it does not matter whether the panic came from an explicit panic!, from a failed assert!/assert_eq!, from an .unwrap() on None, or from an arithmetic overflow in a debug build. For example, a panic raised by assert! is caught the same way:

1
pub fn checked_div(a: i32, b: i32) -> i32 {
2
    assert!(b != 0, "division by zero is undefined");
3
    a / b
4
}
5

6
#[cfg(test)]
7
mod tests {
8
    use super::*;
9

10
    #[test]
11
    #[should_panic(expected = "division by zero")]
12
    fn divide_by_zero_panics() {
13
        checked_div(10, 0);
14
    }
15
}

1
running 1 test
2
test tests::divide_by_zero_panics - should panic ... ok
3

4
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Tests can return `Result<(), E>` to use `?`

A test function may return Result<(), E> for any error type E that implements Debug. The runner treats Ok(()) as a pass and any Err(e) as a failure, printing the error with its Debug representation. This unlocks the ? operator inside the test body:

1
#[test]
2
fn parses_white() -> Result<(), ParseIntError> {
3
    let color = parse_hex_color("#ffffff")?; // `?` returns Err on failure
4
    assert_eq!(color, Rgb { r: 255, g: 255, b: 255 });
5
    Ok(()) // explicit success value is required
6
}

Without this feature you would have to write parse_hex_color("#ffffff").unwrap() on every fallible line. The Result return type lets you write the same straight-line “happy path” code you would write in the library itself — see The ? Operator for the full mechanics of ?. The error type can be anything Debug: a concrete error like ParseIntError, a custom enum, or the catch-all Box<dyn std::error::Error> when several different errors flow through one test.

When such a test does fail, the Debug of the returned error is shown under the test’s name. A test that propagates a ParseIntError from invalid hex prints:

1
running 1 test
2
test tests::rejects_garbage ... FAILED
3

4
failures:
5

6
---- tests::rejects_garbage stdout ----
7
Error: ParseIntError { kind: InvalidDigit }
8

9

10
failures:
11
    tests::rejects_garbage
12

13
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Note: Result-returning tests cannot be combined with #[should_panic]. The two model opposite outcomes: #[should_panic] says “this must panic,” while a Result test says “this must finish and return Ok.” A test that needs to assert an Err value should return Result and check the error explicitly (shown below), not use #[should_panic].

Key Differences

Concern	TypeScript (Jest/Vitest)	Rust
Assert that code throws/panics	`expect(() => fn()).toThrow("msg")`	`#[should_panic(expected = "msg")]` on the test
Pass a callback vs. run inline	Must wrap in `() => ...` so the matcher catches the throw	Body runs inline; the attribute inverts pass/fail
Message matching	Substring (string arg) or regex (`/.../` )	Substring only (`str::contains`); no regex
Fallible test body	`async` test; rejected `await`/throw fails it	`-> Result<(), E>` lets `?` propagate `Err`
Explicit success value	Implicit (test returns `undefined`)	Must end with `Ok(())`
Assert on the error value	`try { ... } catch (e) { expect(e).toEqual(...) }`	Return `Result` and check `.unwrap_err()`, or `match`
What “panic” / “throw” means	Any thrown value unwinds the stack	A `panic!` is an unrecoverable bug signal, not control flow

The single most important conceptual difference: in TypeScript, throw is an ordinary, expected control-flow mechanism — you throw to signal validation failures and catch to recover. In Rust, a panic signals an unrecoverable bug and is not how you report expected failures; recoverable failures return Result. So #[should_panic] is for testing genuine “this should be impossible” invariants (a precondition violation, an index out of bounds), whereas testing an expected failure — bad user input, a missing file — means asserting on a returned Err, not on a panic. See Panicking for the panic-vs-Result decision.

Common Pitfalls

Pitfall 1: bare `#[should_panic]` passing for the wrong reason

A test marked with the bare attribute passes if the body panics for any reason. If you later introduce a bug — say, an out-of-bounds index before the line you meant to test — the test still passes, hiding the regression.

1
#[test]
2
#[should_panic] // passes if ANY panic occurs, even an unrelated one
3
fn overdraw_panics() {
4
    let accounts = vec![100u32];
5
    let _ = accounts[5]; // this panics first — test "passes" for the wrong reason!
6
    withdraw(accounts[0], 150);
7
}

Fix: always pin the message with expected, so an unrelated panic (here, the slice-index panic index out of bounds) fails the substring check instead of silently satisfying it.

Pitfall 2: a `#[should_panic]` test that does not panic

If the body completes normally, the test fails. This is the failure mode you want (it tells you the panic you expected never happened), but the message surprises newcomers:

1
#[test]
2
#[should_panic]
3
fn does_not_actually_panic() {
4
    let _ = 2 + 2; // no panic — so the test fails
5
}

1
running 1 test
2
test tests::does_not_actually_panic - should panic ... FAILED
3

4
failures:
5

6
---- tests::does_not_actually_panic stdout ----
7
note: test did not panic as expected at src/lib.rs:9:8
8

9
failures:
10
    tests::does_not_actually_panic
11

12
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Pitfall 3: using `?` in a test that does not return `Result`

The ? operator only works in a function whose return type can carry the error. A default test returns (), so ? will not compile:

1
#[test]
2
fn parses_ff() {                       // returns () — no place for `?` to send the Err
3
    let value = parse_hex_byte("ff")?; // does not compile (E0277)
4
    assert_eq!(value, 255);
5
}

The real compiler error:

1
error[E0277]: the `?` operator can only be used in a function that returns `Result` or `Option` (or another type that implements `FromResidual`)
2
  --> src/lib.rs:14:41
3
   |
4
13 |     fn parses_ff() {
5
   |     -------------- this function should return `Result` or `Option` to accept `?`
6
14 |         let value = parse_hex_byte("ff")?;
7
   |                                         ^ cannot use the `?` operator in a function that returns `()`
8
   |
9
help: consider adding return type
10
   |
11
13 ~     fn parses_ff() -> Result<(), Box<dyn std::error::Error>> {
12
14 |         let value = parse_hex_byte("ff")?;
13
15 |         assert_eq!(value, 255);
14
16 ~         Ok(())
15
17 ~     }

Fix: add the return type the compiler suggests (-> Result<(), Box<dyn std::error::Error>> or a concrete error type) and end the body with Ok(()).

Pitfall 4: trying to assert an `Err` value with `#[should_panic]`

A returned Err is not a panic, so #[should_panic] will never trigger on it — the test would fail with “did not panic.” To assert that a function returns a specific error, return Result from the test and inspect the error directly:

1
#[test]
2
fn missing_key_is_reported() {
3
    // `unwrap_err` extracts the Err; it panics only if the call unexpectedly succeeds.
4
    let err = parse_hex_color("nothex").unwrap_err();
5
    assert_eq!(err.to_string(), "invalid digit found in string");
6
}

This is the idiomatic way to test the “expected failure” cases that you would write as expect(...).toThrow(...) in Jest but which in Rust are recoverable Result errors, not panics.

Pitfall 5: forgetting `Ok(())` at the end

A Result-returning test must yield a value on the success path. Ending the body with the last assert! is not enough, because assert! evaluates to (), not Result. Add an explicit Ok(()) as the final expression.

Best Practices

Always use expected = "..." with #[should_panic]. The bare form is a foot-gun that passes on any panic. Pick a substring stable enough to survive small wording changes but specific enough to pin the cause.
Reserve #[should_panic] for genuine invariants — preconditions, “unreachable” branches, index bounds — i.e. the things that should panic in production because they represent a bug. Do not use it to test ordinary input validation; that belongs in a Result return and an assert_eq! on the error.
Return Result<(), E> whenever a test body has more than one fallible step, so ? keeps the happy path readable. Use a concrete error type (ParseIntError, your domain enum) when one error flows through, and Box<dyn std::error::Error> when several different errors do.
Assert error values by returning Result and inspecting .unwrap_err() (or match/matches!), not by catching a panic.
Keep Ok(()) at the very end of a Result test; treat it as the test’s “I reached the end successfully” marker.
A Result test that itself fails on the success path can still use .unwrap() for the negative check — e.g. unwrap_err() is fine because a precondition guarantees it. Reserve unconditional unwrap() for tests; in library code, prefer ? (see unwrap and expect).

Real-World Example

A small configuration store that reads typed settings. The error type uses thiserror (add it with cargo add thiserror; this pulls in thiserror = "2"). The test module mixes all three styles: a Result-returning happy-path test that uses ?, a negative test that asserts on the returned Err value, and a test that exercises the Display impl.

1
use std::collections::HashMap;
2
use thiserror::Error;
3

4
/// Errors that can occur while reading a typed setting from the config.
5
#[derive(Debug, Error, PartialEq)]
6
pub enum ConfigError {
7
    #[error("missing required key: {0}")]
8
    Missing(String),
9
    #[error("key `{key}` is not a valid integer: {value:?}")]
10
    NotAnInt { key: String, value: String },
11
}
12

13
/// A tiny string-keyed configuration store.
14
pub struct Config {
15
    values: HashMap<String, String>,
16
}
17

18
impl Config {
19
    pub fn from_pairs(pairs: &[(&str, &str)]) -> Self {
20
        let values = pairs
21
            .iter()
22
            .map(|(k, v)| (k.to_string(), v.to_string()))
23
            .collect();
24
        Config { values }
25
    }
26

27
    /// Read a required `u16` setting, failing if it is missing or malformed.
28
    pub fn require_u16(&self, key: &str) -> Result<u16, ConfigError> {
29
        let raw = self
30
            .values
31
            .get(key)
32
            .ok_or_else(|| ConfigError::Missing(key.to_string()))?;
33
        raw.parse::<u16>().map_err(|_| ConfigError::NotAnInt {
34
            key: key.to_string(),
35
            value: raw.clone(),
36
        })
37
    }
38
}
39

40
#[cfg(test)]
41
mod tests {
42
    use super::*;
43

44
    // A Result-returning test: every `?` either gives us the value or fails
45
    // the test by returning the Err. No `.unwrap()` noise on the happy path.
46
    #[test]
47
    fn reads_valid_port() -> Result<(), ConfigError> {
48
        let config = Config::from_pairs(&[("port", "8080"), ("host", "localhost")]);
49
        let port = config.require_u16("port")?;
50
        assert_eq!(port, 8080);
51
        Ok(())
52
    }
53

54
    // For the *failure* paths we assert on the returned Err directly,
55
    // rather than using `?` (which would abort the test).
56
    #[test]
57
    fn missing_key_is_reported() {
58
        let config = Config::from_pairs(&[("host", "localhost")]);
59
        let err = config.require_u16("port").unwrap_err();
60
        assert_eq!(err, ConfigError::Missing("port".to_string()));
61
    }
62

63
    #[test]
64
    fn malformed_int_is_reported() -> Result<(), Box<dyn std::error::Error>> {
65
        let config = Config::from_pairs(&[("port", "not-a-number")]);
66
        let err = config.require_u16("port").unwrap_err();
67
        // `to_string()` exercises the `#[error(...)]` Display impl.
68
        assert!(err.to_string().contains("not a valid integer"));
69
        Ok(())
70
    }
71
}

Running cargo test for this module:

1
running 3 tests
2
test tests::malformed_int_is_reported ... ok
3
test tests::missing_key_is_reported ... ok
4
test tests::reads_valid_port ... ok
5

6
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Notice the division of labor: the success path uses ? for clean propagation, the failure paths use unwrap_err() and assert on the ConfigError value, and none of them uses #[should_panic] — because none of these are bugs, they are recoverable errors. That is the idiomatic Rust split.

Exercises

Exercise 1: assert a precondition panic

Difficulty: Easy

Objective: Use #[should_panic(expected = "...")] to verify that a method panics when called on an invalid state.

Instructions:

Given the Stack<T> below, whose pop panics on an empty stack, write a test that confirms calling pop on a fresh stack panics with a message containing "empty stack".
Add a second, ordinary test that pushes two values and asserts pop returns them in last-in-first-out order.

1
pub struct Stack<T> {
2
    items: Vec<T>,
3
}
4

5
impl<T> Stack<T> {
6
    pub fn new() -> Self {
7
        Stack { items: Vec::new() }
8
    }
9
    pub fn push(&mut self, item: T) {
10
        self.items.push(item);
11
    }
12
    /// Remove and return the top item, panicking if the stack is empty.
13
    pub fn pop(&mut self) -> T {
14
        self.items.pop().expect("pop called on an empty stack")
15
    }
16
}
17

18
#[cfg(test)]
19
mod tests {
20
    use super::*;
21
    // TODO: write the two tests
22
}

Solution

1
pub struct Stack<T> {
2
    items: Vec<T>,
3
}
4

5
impl<T> Stack<T> {
6
    pub fn new() -> Self {
7
        Stack { items: Vec::new() }
8
    }
9
    pub fn push(&mut self, item: T) {
10
        self.items.push(item);
11
    }
12
    pub fn pop(&mut self) -> T {
13
        self.items.pop().expect("pop called on an empty stack")
14
    }
15
}
16

17
#[cfg(test)]
18
mod tests {
19
    use super::*;
20

21
    #[test]
22
    #[should_panic(expected = "empty stack")]
23
    fn pop_on_empty_panics() {
24
        let mut stack: Stack<i32> = Stack::new();
25
        stack.pop();
26
    }
27

28
    #[test]
29
    fn push_then_pop() {
30
        let mut stack = Stack::new();
31
        stack.push(1);
32
        stack.push(2);
33
        assert_eq!(stack.pop(), 2);
34
        assert_eq!(stack.pop(), 1);
35
    }
36
}

The expected substring matches the message inside .expect(...). Running cargo test reports pop_on_empty_panics - should panic ... ok and push_then_pop ... ok.

Exercise 2: convert an `unwrap`-heavy test to a `Result` test

Difficulty: Medium

Objective: Replace .unwrap() calls in a test body with the ? operator by giving the test a Result return type.

Instructions:

The parser below turns a "x,y" row into a Point. Write a test parses_a_point that parses "3, 4" and asserts it equals Point { x: 3, y: 4 }.
Use ? rather than .unwrap(), which means the test must return Result<(), ParseError> and end with Ok(()).

1
use std::num::ParseIntError;
2

3
#[derive(Debug, PartialEq)]
4
pub struct Point {
5
    pub x: i32,
6
    pub y: i32,
7
}
8

9
#[derive(Debug, PartialEq)]
10
pub enum ParseError {
11
    WrongFieldCount(usize),
12
    BadInt(ParseIntError),
13
}
14

15
impl From<ParseIntError> for ParseError {
16
    fn from(e: ParseIntError) -> Self {
17
        ParseError::BadInt(e)
18
    }
19
}
20

21
pub fn parse_point(row: &str) -> Result<Point, ParseError> {
22
    let fields: Vec<&str> = row.split(',').collect();
23
    if fields.len() != 2 {
24
        return Err(ParseError::WrongFieldCount(fields.len()));
25
    }
26
    let x = fields[0].trim().parse::<i32>()?;
27
    let y = fields[1].trim().parse::<i32>()?;
28
    Ok(Point { x, y })
29
}
30

31
#[cfg(test)]
32
mod tests {
33
    use super::*;
34
    // TODO: write `parses_a_point` using `?`
35
}

Solution

1
use std::num::ParseIntError;
2

3
#[derive(Debug, PartialEq)]
4
pub struct Point {
5
    pub x: i32,
6
    pub y: i32,
7
}
8

9
#[derive(Debug, PartialEq)]
10
pub enum ParseError {
11
    WrongFieldCount(usize),
12
    BadInt(ParseIntError),
13
}
14

15
impl From<ParseIntError> for ParseError {
16
    fn from(e: ParseIntError) -> Self {
17
        ParseError::BadInt(e)
18
    }
19
}
20

21
pub fn parse_point(row: &str) -> Result<Point, ParseError> {
22
    let fields: Vec<&str> = row.split(',').collect();
23
    if fields.len() != 2 {
24
        return Err(ParseError::WrongFieldCount(fields.len()));
25
    }
26
    let x = fields[0].trim().parse::<i32>()?;
27
    let y = fields[1].trim().parse::<i32>()?;
28
    Ok(Point { x, y })
29
}
30

31
#[cfg(test)]
32
mod tests {
33
    use super::*;
34

35
    #[test]
36
    fn parses_a_point() -> Result<(), ParseError> {
37
        let point = parse_point("3, 4")?;
38
        assert_eq!(point, Point { x: 3, y: 4 });
39
        Ok(())
40
    }
41
}

Because the test returns Result<(), ParseError>, the ? on parse_point propagates any Err as a test failure, and the happy path stays free of .unwrap(). The test reports parses_a_point ... ok.

Exercise 3: test both the success and the two failure modes

Difficulty: Medium-Hard

Objective: Cover one function with a Result test for success and Err-value assertions for each failure path — without #[should_panic], because these are recoverable errors, not bugs.

Instructions:

Using the same parse_point from Exercise 2, write three tests:

wrong_field_count_is_an_error: parsing "1,2,3" returns Err(ParseError::WrongFieldCount(3)).
bad_int_is_an_error: parsing a valid "10,-7" succeeds via ?, and parsing "x,2" returns a ParseError::BadInt(_).
Decide for each whether the test should return Result and explain (in a comment) why you did not use #[should_panic].

Solution

1
use std::num::ParseIntError;
2

3
#[derive(Debug, PartialEq)]
4
pub struct Point {
5
    pub x: i32,
6
    pub y: i32,
7
}
8

9
#[derive(Debug, PartialEq)]
10
pub enum ParseError {
11
    WrongFieldCount(usize),
12
    BadInt(ParseIntError),
13
}
14

15
impl From<ParseIntError> for ParseError {
16
    fn from(e: ParseIntError) -> Self {
17
        ParseError::BadInt(e)
18
    }
19
}
20

21
pub fn parse_point(row: &str) -> Result<Point, ParseError> {
22
    let fields: Vec<&str> = row.split(',').collect();
23
    if fields.len() != 2 {
24
        return Err(ParseError::WrongFieldCount(fields.len()));
25
    }
26
    let x = fields[0].trim().parse::<i32>()?;
27
    let y = fields[1].trim().parse::<i32>()?;
28
    Ok(Point { x, y })
29
}
30

31
#[cfg(test)]
32
mod tests {
33
    use super::*;
34

35
    // A wrong field count is a recoverable, *expected* failure — not a bug —
36
    // so we assert on the returned Err value rather than expecting a panic.
37
    #[test]
38
    fn wrong_field_count_is_an_error() {
39
        let err = parse_point("1,2,3").unwrap_err();
40
        assert_eq!(err, ParseError::WrongFieldCount(3));
41
    }
42

43
    // Same reasoning: a malformed integer returns Err, it does not panic.
44
    // This test returns Result so the *valid* row can use `?` on the happy path.
45
    #[test]
46
    fn bad_int_is_an_error() -> Result<(), ParseError> {
47
        let ok = parse_point("10,-7")?;
48
        assert_eq!(ok, Point { x: 10, y: -7 });
49
        assert!(matches!(parse_point("x,2"), Err(ParseError::BadInt(_))));
50
        Ok(())
51
    }
52
}

Both failures are returned as Err values, so #[should_panic] would be wrong here — it would only catch a panic, and parse_point never panics. matches! is a concise way to assert the variant of an error without comparing the inner ParseIntError, which does not have a convenient literal. The suite reports wrong_field_count_is_an_error ... ok and bad_int_is_an_error ... ok.

Testing Panics and Returning Result from Tests

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

#[should_panic] inverts the pass/fail condition

expected matches a substring, not the whole message

#[should_panic] catches any panic, including assert! and overflow

Tests can return Result<(), E> to use ?

Key Differences

Common Pitfalls

Pitfall 1: bare #[should_panic] passing for the wrong reason

Pitfall 2: a #[should_panic] test that does not panic

Pitfall 3: using ? in a test that does not return Result

Pitfall 4: trying to assert an Err value with #[should_panic]

Pitfall 5: forgetting Ok(()) at the end

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: assert a precondition panic

Exercise 2: convert an unwrap-heavy test to a Result test

Exercise 3: test both the success and the two failure modes

Testing Panics and Returning `Result` from Tests

`#[should_panic]` inverts the pass/fail condition

`expected` matches a substring, not the whole message

`#[should_panic]` catches any panic, including `assert!` and overflow

Tests can return `Result<(), E>` to use `?`

Pitfall 1: bare `#[should_panic]` passing for the wrong reason

Pitfall 2: a `#[should_panic]` test that does not panic

Pitfall 3: using `?` in a test that does not return `Result`

Pitfall 4: trying to assert an `Err` value with `#[should_panic]`

Pitfall 5: forgetting `Ok(())` at the end

Exercise 2: convert an `unwrap`-heavy test to a `Result` test