Assertions: `assert!`, `assert_eq!`, and `assert_ne!`

20 min read

Assertions are the checks inside your tests that decide pass or fail. Rust ships three built-in assertion macros that cover almost everything you reach for expect(...).toBe(...) for in Jest or Vitest — with a key twist: when an assertion fails, Rust panics and prints a precise, value-rich report instead of throwing a JavaScript exception.

Quick Overview

Rust’s standard library provides assert!, assert_eq!, and assert_ne! — no matcher library, no import, no setup. They are available everywhere because they live in the prelude. A failing assertion panics with the file, line, and the actual values involved, which is how a #[test] function is marked as failed. The current stable toolchain is Rust 1.96.0 on the 2024 edition; cargo new selects it automatically, and these macros have been stable since Rust 1.0.

Note: This page covers the assertion macros themselves and how their failure output reads. For writing and running the surrounding tests, see Unit Tests; for asserting that code panics on purpose, see Testing for Panics; for returning Result from a test and using ?, also see Testing for Panics.

TypeScript/JavaScript Example

In Jest or Vitest you assert through a fluent matcher API: expect(value) returns an object, and you chain a matcher like .toBe, .toEqual, or .toBeTruthy. The matcher both performs the comparison and formats the diff when it fails.

1
export interface LineItem {
2
  sku: string;
3
  quantity: number;
4
}
5

6
export function slugify(title: string): string {
7
  return title
8
    .trim()
9
    .toLowerCase()
10
    .replace(/[^a-z0-9]+/g, "-")
11
    .replace(/^-+|-+$/g, "");
12
}
13

14
export function parsePort(raw: string): number | null {
15
  const n = Number(raw.trim());
16
  return Number.isInteger(n) && n > 0 && n <= 65535 ? n : null;
17
}

1
// cart.test.ts (Vitest / Jest share this API)
2
import { describe, it, expect } from "vitest";
3
import { slugify, parsePort } from "./cart";
4

5
describe("slugify", () => {
6
  it("lowercases and collapses separators", () => {
7
    expect(slugify("  Rust   &  TS  ")).toBe("rust-ts");
8
  });
9

10
  it("rejects port 0", () => {
11
    expect(parsePort("0")).toBeNull();
12
    // A custom message is the optional second arg to the matcher in Vitest:
13
    expect(parsePort("8080"), "8080 should be a valid port").not.toBeNull();
14
  });
15
});

Key things to notice for the comparison below:

expect(...).toBe(x) is reference/Object.is equality; expect(...).toEqual(x) is deep structural equality. JavaScript devs constantly choose between them.
A failing matcher throws, which the test runner catches and reports.
Custom failure messages are matcher-specific second arguments (and not all matchers accept them).

Rust Equivalent

Rust collapses all of this into three macros. There is no expect() wrapper and no .toBe vs .toEqual distinction — assert_eq! always compares by value (via the PartialEq trait), which is the structural comparison you almost always want.

1
pub fn slugify(title: &str) -> String {
2
    title
3
        .trim()
4
        .to_lowercase()
5
        .chars()
6
        .map(|c| if c.is_alphanumeric() { c } else { '-' })
7
        .collect::<String>()
8
        .split('-')
9
        .filter(|s| !s.is_empty())
10
        .collect::<Vec<_>>()
11
        .join("-")
12
}
13

14
pub fn parse_port(raw: &str) -> Option<u16> {
15
    raw.trim().parse::<u16>().ok().filter(|&p| p > 0)
16
}
17

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

22
    #[test]
23
    fn slug_lowercases_and_collapses() {
24
        assert_eq!(slugify("  Rust   &  TS  "), "rust-ts");
25
    }
26

27
    #[test]
28
    fn port_rejects_zero() {
29
        assert!(parse_port("0").is_none());
30
        // assert_ne! with an optional custom message (note the trailing args).
31
        assert_ne!(parse_port("8080"), None, "8080 should be a valid port");
32
    }
33
}

Running cargo test reports each #[test] function:

1
running 2 tests
2
test tests::port_rejects_zero ... ok
3
test tests::slug_lowercases_and_collapses ... ok
4

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

The three macros, at a glance:

Macro	Checks	Jest/Vitest analogue
`assert!(expr)`	`expr` is `true`	`expect(x).toBe(true)` / `.toBeTruthy()`
`assert_eq!(a, b)`	`a == b`	`expect(a).toEqual(b)`
`assert_ne!(a, b)`	`a != b`	`expect(a).not.toEqual(b)`

Detailed Explanation

`assert!` takes a `bool`, not a “truthy” value

assert!(cond) panics unless cond is exactly the boolean true. This is the biggest mental shift from JavaScript: there is no truthiness. You cannot write assert!(items.len()) hoping that a non-zero length counts as true — items.len() is a usize, and Rust will reject it at compile time:

1
#[cfg(test)]
2
mod tests {
3
    #[test]
4
    fn non_bool_assert() {
5
        let count = 3;
6
        assert!(count); // does not compile (error[E0308]: mismatched types)
7
    }
8
}

The real compiler error:

1
error[E0308]: mismatched types
2
 --> src/lib.rs:6:9
3
  |
4
6 |         assert!(count); // does not compile (error[E0308]: mismatched types)
5
  |         ^^^^^^^^^^^^^^ expected `bool`, found integer
6

7
For more information about this error, try `rustc --explain E0308`.

You must write an explicit comparison: assert!(count > 0) or assert!(count == 3). Unlike a JavaScript if (count), this forces you to state what “true” means, which catches a whole category of “I meant === 0” bugs.

`assert_eq!` / `assert_ne!` print both sides on failure

The reason to prefer assert_eq!(a, b) over assert!(a == b) is the failure message. assert!(a == b) can only tell you “the expression was false.” assert_eq! knows both operands, so it prints them:

1
pub fn slugify(title: &str) -> String {
2
    // BUG (intentional): does not collapse repeated separators.
3
    title
4
        .trim()
5
        .to_lowercase()
6
        .replace(|c: char| !c.is_alphanumeric(), "-")
7
}
8

9
#[cfg(test)]
10
mod tests {
11
    use super::*;
12

13
    #[test]
14
    fn slug_collapses_separators() {
15
        assert_eq!(slugify("Hello, World!"), "hello-world"); // fails at runtime
16
    }
17
}

The real output from cargo test:

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

4
failures:
5

6
---- tests::slug_collapses_separators stdout ----
7

8
thread 'tests::slug_collapses_separators' panicked at src/lib.rs:12:9:
9
assertion `left == right` failed
10
  left: "hello--world-"
11
 right: "hello-world"
12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
13

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

left is the first argument (your computed value), right is the second (your expected value). The convention is actual on the left, expected on the right, mirroring assert_eq!(got, want). Rust does not enforce this — the labels are literally left/right, not “actual”/“expected” — but staying consistent makes failures readable.

A failed assertion is a panic, which is how a test fails

There is no throw/catch here. assert_eq! expands to roughly “if the values differ, call panic! with this message.” The test harness runs each #[test] function, catches the panic via the unwinding machinery, and records the test as FAILED. That is the entire mechanism — assertions and #[test] are decoupled. You can even call these macros in non-test code (e.g. to enforce an invariant at startup), where a failure aborts the program. See Panics for how panicking works in general.

Comparing requires `PartialEq`; printing the failure requires `Debug`

assert_eq!(a, b) needs to do two things when it fails:

Compare a and b — so both must implement the PartialEq trait (that is what the == operator dispatches to).
Print a and b in the failure message — so both must implement Debug, the formatter used by {:?}.

For your own structs and enums, you get both with a one-line derive. This is the single most important habit for testing custom types in Rust:

1
#[derive(Debug, PartialEq)]
2
pub struct LineItem {
3
    pub sku: String,
4
    pub quantity: u32,
5
}
6

7
pub fn parse_line(raw: &str) -> Option<LineItem> {
8
    let (sku, qty) = raw.split_once('x')?;
9
    Some(LineItem {
10
        sku: sku.trim().to_string(),
11
        quantity: qty.trim().parse().ok()?,
12
    })
13
}
14

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

19
    #[test]
20
    fn parses_line_item() {
21
        let got = parse_line("WIDGET x 3").unwrap();
22
        // Expected quantity is wrong on purpose to show the diff.
23
        assert_eq!(
24
            got,
25
            LineItem { sku: "WIDGET".to_string(), quantity: 5 }
26
        ); // fails at runtime
27
    }
28
}

Because LineItem derives Debug, the failure prints the full structures, not just “not equal”:

1
thread 'tests::parses_line_item' panicked at src/lib.rs:23:9:
2
assertion `left == right` failed
3
  left: LineItem { sku: "WIDGET", quantity: 3 }
4
 right: LineItem { sku: "WIDGET", quantity: 5 }

This is the equivalent of Jest’s structural diff for objects, except you opt into it explicitly with #[derive(Debug)]. Unlike TypeScript, where console.log(obj) and matcher diffs work on any value reflectively, Rust has no runtime reflection — the Debug impl is generated at compile time, and a type without it simply cannot be auto-printed.

Key Differences

Concept	TypeScript (Jest/Vitest)	Rust
API shape	Fluent `expect(x).matcher(y)`	Macros `assert_eq!(x, y)` (no wrapper object)
Import needed	`import { expect } from "vitest"`	None — in the prelude, always available
Equality kinds	`toBe` (Object.is) vs `toEqual` (deep)	One `assert_eq!`, always by value via `PartialEq`
Truthiness	`expect(x).toBeTruthy()` accepts any value	`assert!` requires a real `bool` (no truthiness)
Failure mechanism	Throws an `Error` the runner catches	Panics; the harness records the panic as a failure
Printing values	Reflective, automatic for any object	Needs `Debug` (usually `#[derive(Debug)]`)
Comparing custom types	Automatic deep compare	Needs `PartialEq` (usually `#[derive(PartialEq)]`)
Custom message	Matcher-specific extra argument	Trailing `format!`-style args on any of the three macros
Approximate float compare	`expect(x).toBeCloseTo(y)`	No built-in; compare `(x - y).abs() < eps` yourself

The deepest conceptual difference: in JavaScript the matcher library does the heavy lifting at runtime, inspecting arbitrary values reflectively. In Rust the work is split between traits resolved at compile time (PartialEq for comparing, Debug for printing) and a tiny macro that wires them into a panic!. If a type doesn’t implement those traits, the test does not compile — the failure moves from runtime to compile time, which is the recurring Rust theme.

Custom Failure Messages

All three macros accept optional trailing arguments after the values, using the exact same syntax as println! — a format string plus interpolated values. This is the analogue of a Jest custom matcher message, and it is appended to the standard report rather than replacing it.

1
pub fn discount_price(price: f64, percent_off: f64) -> f64 {
2
    price * (1.0 - percent_off / 100.0)
3
}
4

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

9
    #[test]
10
    fn plain_assert_fails() {
11
        let total = discount_price(100.0, 25.0);
12
        assert!(total < 50.0); // false: total is 75.0
13
    }
14

15
    #[test]
16
    fn custom_message_assert() {
17
        let total = discount_price(100.0, 25.0);
18
        assert!(
19
            total < 50.0,
20
            "expected discounted total under 50, got {total}"
21
        ); // fails with the custom message
22
    }
23

24
    #[test]
25
    fn custom_message_eq() {
26
        let users = vec!["alice", "bob"];
27
        assert_eq!(
28
            users.len(),
29
            3,
30
            "roster should have 3 members but had {}: {:?}",
31
            users.len(),
32
            users
33
        ); // fails with the custom message
34
    }
35
}

The real output shows how a bare assert! is the least informative, and how the custom message rides along with assert_eq!’s automatic left/right dump:

1
---- tests::custom_message_eq stdout ----
2
thread 'tests::custom_message_eq' panicked at src/lib.rs:27:9:
3
assertion `left == right` failed: roster should have 3 members but had 2: ["alice", "bob"]
4
  left: 2
5
 right: 3
6

7
---- tests::custom_message_assert stdout ----
8
thread 'tests::custom_message_assert' panicked at src/lib.rs:18:9:
9
expected discounted total under 50, got 75
10

11
---- tests::plain_assert_fails stdout ----
12
thread 'tests::plain_assert_fails' panicked at src/lib.rs:12:9:
13
assertion failed: total < 50.0

Notice that the bare assert!(total < 50.0) can only echo the source text of the condition (total < 50.0) — it cannot show that total was 75. That is exactly when a custom message earns its keep: for assert!, include the runtime value in the message so a failure is debuggable.

Tip: The format string uses inline captures like {total} for variables in scope (stable since Rust 1.58). Use {:?} (Debug) for collections and structs, and positional {} for values you pass explicitly. Avoid the old redundant format!("{x}", x = x) style.

Common Pitfalls

Forgetting `#[derive(PartialEq)]` on a compared type

If you assert_eq! two values of a type that can’t be compared with ==, the error is about the missing trait, not about the assertion:

1
#[derive(Debug)] // has Debug, but NO PartialEq
2
pub struct Point {
3
    pub x: i32,
4
    pub y: i32,
5
}
6

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

11
    #[test]
12
    fn points_equal() {
13
        let a = Point { x: 1, y: 2 };
14
        let b = Point { x: 1, y: 2 };
15
        assert_eq!(a, b); // does not compile (error[E0369])
16
    }
17
}

The real compiler error tells you precisely what to add:

1
error[E0369]: binary operation `==` cannot be applied to type `Point`
2
  --> src/lib.rs:15:9
3
   |
4
15 |         assert_eq!(a, b); // does not compile (error[E0369])
5
   |         ^^^^^^^^^^^^^^^^
6
   |         |
7
   |         Point
8
   |         Point
9
   |
10
note: an implementation of `PartialEq` might be missing for `Point`
11
help: consider annotating `Point` with `#[derive(PartialEq)]`

Forgetting `#[derive(Debug)]` (so the failure can’t be printed)

This is the more confusing one, because the type compares fine — the error only appears because the failure message needs to print the values. If Point derives PartialEq but not Debug:

1
error[E0277]: `Point` doesn't implement `Debug`
2
  --> src/lib.rs:15:9
3
   |
4
15 |         assert_eq!(a, b); // does not compile (error[E0277])
5
   |         ^^^^^^^^^^^^^^^^ the trait `Debug` is not implemented for `Point`
6
   |
7
   = note: add `#[derive(Debug)]` to `Point` or manually `impl Debug for Point`
8
help: consider annotating `Point` with `#[derive(Debug)]`

The fix for both pitfalls is the same single line you should make a reflex on any type you test: #[derive(Debug, PartialEq)].

Comparing floats with `assert_eq!`

JavaScript devs know 0.1 + 0.2 !== 0.3, but it is easy to forget when reaching for assert_eq!. Rust uses the same IEEE-754 f64, so exact equality fails the same way:

1
pub fn add(a: f64, b: f64) -> f64 {
2
    a + b
3
}
4

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

9
    #[test]
10
    fn naive_float_eq() {
11
        assert_eq!(add(0.1, 0.2), 0.3); // fails: not exactly 0.3
12
    }
13

14
    #[test]
15
    fn epsilon_compare() {
16
        let got = add(0.1, 0.2);
17
        let want = 0.3;
18
        assert!(
19
            (got - want).abs() < 1e-10,
20
            "expected ~{want}, got {got} (diff {})",
21
            (got - want).abs()
22
        );
23
    }
24
}

The naive test fails exactly as it would in Node, and the epsilon test passes:

1
running 2 tests
2
test tests::epsilon_compare ... ok
3
test tests::naive_float_eq ... FAILED
4

5
---- tests::naive_float_eq stdout ----
6
thread 'tests::naive_float_eq' panicked at src/lib.rs:12:9:
7
assertion `left == right` failed
8
  left: 0.30000000000000004
9
 right: 0.3

Rust’s standard library deliberately has no assert_approx_eq! — compare against an epsilon yourself, or pull in a crate (see Best Practices). This is Jest’s toBeCloseTo, hand-rolled.

Putting a stray comma where a custom message goes

assert!(a == b,) or assert_eq!(a, b,) with a trailing comma is fine, but assert_eq!(a, b, c) treats c as the format string of a custom message. If c isn’t a string literal you’ll get a format-string error, not the comparison you intended. The third positional argument is always the message, never a third value to compare.

Best Practices

Default to assert_eq!/assert_ne! over assert! for equality. They print both operands; assert!(a == b) cannot. Reserve bare assert! for genuine boolean predicates (assert!(cart.is_empty()), assert!(result.is_ok())).
Derive Debug and PartialEq on every type you assert on. #[derive(Debug, PartialEq)] is idiomatic and free; without it your tests won’t compile.
Order arguments as (got, want) — actual first, expected second. The labels are only left/right, so consistency is on you, but it makes every failure read the same way.
Put runtime values in assert! messages. Since assert! can’t introspect operands, assert!(n > 0, "n was {n}") turns an opaque failure into an obvious one.

For structs with many fields, consider the pretty_assertions crate as a drop-in replacement. It overrides assert_eq!/assert_ne! to print a colored, line-by-line diff — much easier to scan than two long one-line Debug dumps. Add it as a dev-dependency:

1
cargo add pretty_assertions --dev

1
#[derive(Debug, PartialEq)]
2
pub struct Config {
3
    pub host: String,
4
    pub port: u16,
5
    pub tls: bool,
6
}
7

8
pub fn default_config() -> Config {
9
    Config { host: "localhost".to_string(), port: 8080, tls: false }
10
}
11

12
#[cfg(test)]
13
mod tests {
14
    use super::*;
15
    use pretty_assertions::assert_eq; // shadow std's macro in this module only
16

17
    #[test]
18
    fn config_matches() {
19
        assert_eq!(
20
            default_config(),
21
            Config { host: "localhost".to_string(), port: 9090, tls: true }
22
        ); // fails with a diff
23
    }
24
}

The failure highlights only the fields that differ (colors shown here as </> markers):

1
thread 'tests::config_matches' panicked at src/lib.rs:19:9:
2
assertion failed: `(left == right)`
3

4
Diff < left / right > :
5
 Config {
6
     host: "localhost",
7
<    port: 8080,
8
<    tls: false,
9
>    port: 9090,
10
>    tls: true,
11
 }

There’s also debug_assert! / debug_assert_eq! / debug_assert_ne!. These are identical but compile to nothing in release builds (cargo build --release). They are for invariants in library code that you don’t want to pay for in production — not generally for tests, since tests run in debug mode anyway.

Real-World Example

A small shopping-cart module with a test suite that uses all three macros, a custom message, and the Debug, PartialEq derive habit. This is the shape of a typical unit-test module living alongside the code it tests.

1
//! A tiny shopping-cart module demonstrating the assertion macros.
2

3
#[derive(Debug, Clone, PartialEq)]
4
pub struct LineItem {
5
    pub sku: String,
6
    pub unit_price_cents: u64,
7
    pub quantity: u32,
8
}
9

10
#[derive(Debug, Default)]
11
pub struct Cart {
12
    items: Vec<LineItem>,
13
}
14

15
impl Cart {
16
    pub fn new() -> Self {
17
        Cart::default()
18
    }
19

20
    /// Adds an item; merges quantity if the SKU already exists.
21
    pub fn add(&mut self, sku: &str, unit_price_cents: u64, quantity: u32) {
22
        if let Some(existing) = self.items.iter_mut().find(|i| i.sku == sku) {
23
            existing.quantity += quantity;
24
        } else {
25
            self.items.push(LineItem {
26
                sku: sku.to_string(),
27
                unit_price_cents,
28
                quantity,
29
            });
30
        }
31
    }
32

33
    pub fn items(&self) -> &[LineItem] {
34
        &self.items
35
    }
36

37
    pub fn total_cents(&self) -> u64 {
38
        self.items
39
            .iter()
40
            .map(|i| i.unit_price_cents * i.quantity as u64)
41
            .sum()
42
    }
43

44
    pub fn is_empty(&self) -> bool {
45
        self.items.is_empty()
46
    }
47
}
48

49
#[cfg(test)]
50
mod tests {
51
    use super::*;
52

53
    #[test]
54
    fn new_cart_is_empty() {
55
        let cart = Cart::new();
56
        assert!(cart.is_empty(), "a freshly constructed cart must be empty");
57
        assert_eq!(cart.total_cents(), 0);
58
    }
59

60
    #[test]
61
    fn adding_distinct_items_keeps_them_separate() {
62
        let mut cart = Cart::new();
63
        cart.add("APPLE", 50, 3);
64
        cart.add("BREAD", 200, 1);
65

66
        assert_eq!(cart.items().len(), 2);
67
        assert_eq!(cart.total_cents(), 50 * 3 + 200);
68
    }
69

70
    #[test]
71
    fn adding_same_sku_merges_quantity() {
72
        let mut cart = Cart::new();
73
        cart.add("APPLE", 50, 3);
74
        cart.add("APPLE", 50, 2);
75

76
        assert_eq!(
77
            cart.items().len(),
78
            1,
79
            "same SKU should merge into one line, got {:#?}",
80
            cart.items()
81
        );
82
        assert_eq!(cart.items()[0].quantity, 5);
83
        assert_ne!(cart.total_cents(), 0);
84
    }
85
}

All three tests pass:

1
running 3 tests
2
test tests::adding_distinct_items_keeps_them_separate ... ok
3
test tests::adding_same_sku_merges_quantity ... ok
4
test tests::new_cart_is_empty ... ok
5

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

Two details worth copying: LineItem derives Debug, PartialEq so it can appear in assert_eq!, and the merge test uses {:#?} (pretty Debug) in its custom message so that if the merge logic ever regresses, the failure dumps the full item list on multiple lines for easy reading.

Exercises

Exercise 1: Convert and compare

Difficulty: Easy

Objective: Practice all three macros, including an approximate float comparison.

Instructions:

Write celsius_to_fahrenheit(c: f64) -> f64 using the formula c * 9/5 + 32.
In a #[cfg(test)] mod tests, write one test that:
- uses assert_eq! to check that 0.0 C is exactly 32.0 F,
- uses assert! with an epsilon (< 1e-9) to check that 100.0 C is about 212.0 F, including a custom message that prints the actual value,
- uses assert_ne! to confirm 37.0 C is not 0.0 F.

Solution

1
pub fn celsius_to_fahrenheit(c: f64) -> f64 {
2
    c * 9.0 / 5.0 + 32.0
3
}
4

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

9
    #[test]
10
    fn freezing_and_boiling() {
11
        assert_eq!(celsius_to_fahrenheit(0.0), 32.0);
12

13
        let boiling = celsius_to_fahrenheit(100.0);
14
        assert!(
15
            (boiling - 212.0).abs() < 1e-9,
16
            "100C should be ~212F, got {boiling}"
17
        );
18

19
        assert_ne!(celsius_to_fahrenheit(37.0), 0.0);
20
    }
21
}

0.0 and 100.0 happen to convert to values representable exactly, so assert_eq! is safe for freezing; in general prefer the epsilon form for float results, as the boiling check shows.

Exercise 2: Assert on a custom type

Difficulty: Medium

Objective: Experience the Debug + PartialEq requirement firsthand and write a custom failure message.

Instructions:

Define struct Rgb { r: u8, g: u8, b: u8 } and derive whatever traits you need to compare it in assert_eq!.
Write parse_hex(code: &str) -> Option<Rgb> that parses "#RRGGBB" (return None for a missing #, wrong length, or non-hex digits).
Write tests: one asserting parse_hex("#FF8000") equals Some(Rgb { r: 255, g: 128, b: 0 }), and one asserting several malformed inputs return None, each with a custom message saying which input failed.

Solution

1
#[derive(Debug, PartialEq)]
2
pub struct Rgb {
3
    pub r: u8,
4
    pub g: u8,
5
    pub b: u8,
6
}
7

8
pub fn parse_hex(code: &str) -> Option<Rgb> {
9
    let hex = code.strip_prefix('#')?;
10
    if hex.len() != 6 {
11
        return None;
12
    }
13
    let r = u8::from_str_radix(&hex[0..2], 16).ok()?;
14
    let g = u8::from_str_radix(&hex[2..4], 16).ok()?;
15
    let b = u8::from_str_radix(&hex[4..6], 16).ok()?;
16
    Some(Rgb { r, g, b })
17
}
18

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

23
    #[test]
24
    fn parses_valid_hex() {
25
        assert_eq!(parse_hex("#FF8000"), Some(Rgb { r: 255, g: 128, b: 0 }));
26
    }
27

28
    #[test]
29
    fn rejects_bad_input() {
30
        assert_eq!(parse_hex("FF8000"), None, "missing # should be rejected");
31
        assert_eq!(parse_hex("#FFF"), None, "wrong length should be rejected");
32
        assert!(parse_hex("#GG0000").is_none());
33
    }
34
}

Without #[derive(Debug, PartialEq)] on Rgb, the assert_eq! lines fail to compile (E0369 for the missing PartialEq, E0277 for the missing Debug).

Exercise 3: Summary statistics with a structural assertion

Difficulty: Medium-Hard

Objective: Combine Option, a derived struct, and a {:#?}-style failure message.

Instructions:

Define struct Stats { count: usize, sum: i64, max: i64 } with the right derives.
Write summarize(values: &[i64]) -> Option<Stats> that returns None for an empty slice and otherwise computes count, sum, and max.
Write tests that: assert the fields for &[3, 7, 2, 9], and assert that an empty slice yields None with a custom message explaining the expectation. Use .expect(...) to unwrap the non-empty case.

Solution

1
#[derive(Debug, PartialEq)]
2
pub struct Stats {
3
    pub count: usize,
4
    pub sum: i64,
5
    pub max: i64,
6
}
7

8
pub fn summarize(values: &[i64]) -> Option<Stats> {
9
    if values.is_empty() {
10
        return None;
11
    }
12
    Some(Stats {
13
        count: values.len(),
14
        sum: values.iter().sum(),
15
        max: *values.iter().max().unwrap(), // safe: slice is non-empty here
16
    })
17
}
18

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

23
    #[test]
24
    fn summarizes_values() {
25
        let stats = summarize(&[3, 7, 2, 9]).expect("non-empty slice should summarize");
26
        assert_eq!(stats.count, 4);
27
        assert_eq!(stats.sum, 21);
28
        assert_eq!(stats.max, 9);
29
    }
30

31
    #[test]
32
    fn empty_slice_is_none() {
33
        assert_eq!(
34
            summarize(&[]),
35
            None,
36
            "empty input must produce None, not a zeroed Stats"
37
        );
38
    }
39
}

You could also assert the whole struct at once with assert_eq!(stats, Stats { count: 4, sum: 21, max: 9 }) — thanks to the PartialEq derive, comparing the entire value in one assertion is idiomatic and gives the clearest diff on failure.

Assertions: assert!, assert_eq!, and assert_ne!

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

assert! takes a bool, not a “truthy” value

assert_eq! / assert_ne! print both sides on failure

A failed assertion is a panic, which is how a test fails

Comparing requires PartialEq; printing the failure requires Debug

Key Differences

Custom Failure Messages

Common Pitfalls

Forgetting #[derive(PartialEq)] on a compared type

Forgetting #[derive(Debug)] (so the failure can’t be printed)

Comparing floats with assert_eq!

Putting a stray comma where a custom message goes

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Convert and compare

Exercise 2: Assert on a custom type

Exercise 3: Summary statistics with a structural assertion

Assertions: `assert!`, `assert_eq!`, and `assert_ne!`

`assert!` takes a `bool`, not a “truthy” value

`assert_eq!` / `assert_ne!` print both sides on failure

Comparing requires `PartialEq`; printing the failure requires `Debug`

Forgetting `#[derive(PartialEq)]` on a compared type

Forgetting `#[derive(Debug)]` (so the failure can’t be printed)

Comparing floats with `assert_eq!`