Integration Tests: The `tests/` Directory and Black-Box Testing

19 min read

Integration tests in Rust live in a top-level tests/ directory, get compiled as separate crates, and can only see your crate’s public API — exactly the way a real consumer would use it. This page covers how that directory works, how to test the public surface as a black box, and how to share setup code across test files without confusing Cargo.

Quick Overview

In TypeScript/JavaScript you usually drop every test under a tests/ or __tests__ folder and let Jest or Vitest run the lot, regardless of whether a test pokes at internals or only the exported API. Rust draws a sharper line: unit tests live inside your source files and can reach private items, while integration tests live in a sibling tests/ directory, are compiled as independent crates, and are forced to go through your pub interface. That separation makes integration tests a faithful black-box check of what your users will actually be able to call. This page is about the tests/ directory specifically; the unit-tests and test-organization pages cover the in-source side.

TypeScript/JavaScript Example

Here is a small shopping-cart module and a Vitest suite that exercises it end to end. In a typical Node project the tests sit next to (or under) src/ and import the module like any other consumer.

1
// src/cart.ts — the module under test
2
export interface Item {
3
  sku: string;
4
  priceCents: number;
5
}
6

7
export class Cart {
8
  private lines = new Map<string, { item: Item; qty: number }>();
9

10
  add(item: Item, qty: number): void {
11
    if (item.sku === "") throw new Error("SKU must not be empty");
12
    const line = this.lines.get(item.sku);
13
    if (line) line.qty += qty;
14
    else this.lines.set(item.sku, { item, qty });
15
  }
16

17
  quantity(sku: string): number {
18
    return this.lines.get(sku)?.qty ?? 0;
19
  }
20

21
  totalCents(): number {
22
    let sum = 0;
23
    for (const { item, qty } of this.lines.values()) sum += item.priceCents * qty;
24
    return sum;
25
  }
26
}
27

28
export function applyDiscount(totalCents: number, percent: number): number {
29
  const p = Math.min(percent, 100);
30
  return totalCents - Math.floor((totalCents * p) / 100);
31
}

1
// tests/cart.test.ts — Vitest integration-style test
2
import { describe, it, expect } from "vitest";
3
import { Cart, applyDiscount } from "../src/cart";
4

5
// A shared helper used by several tests.
6
function sampleCart(): Cart {
7
  const cart = new Cart();
8
  cart.add({ sku: "BOOK-01", priceCents: 1299 }, 2);
9
  cart.add({ sku: "PEN-07", priceCents: 250 }, 4);
10
  return cart;
11
}
12

13
describe("cart checkout", () => {
14
  it("totals prices times quantities", () => {
15
    expect(sampleCart().totalCents()).toBe(3598);
16
  });
17

18
  it("applies a percentage discount", () => {
19
    expect(applyDiscount(sampleCart().totalCents(), 10)).toBe(3239);
20
  });
21
});

Note two things a TypeScript developer takes for granted: the test imports from a relative path (../src/cart), and the helper sampleCart is just a function defined in the same file. Nothing stops a Vitest test from reaching into internals either — private is only enforced by the type-checker, not at runtime, so a determined test could still poke at (cart as any).lines.

Rust Equivalent

The same library as a Rust crate. Integration tests go in tests/, use the crate by its package name (not by a relative path), and the compiler refuses to let them touch private fields like lines.

1
cart/
2
├── Cargo.toml
3
├── src/
4
│   └── lib.rs            # the library crate
5
└── tests/                # each .rs file here is its OWN test crate
6
    ├── cart_checkout.rs
7
    ├── cart_lifecycle.rs
8
    └── common/
9
        └── mod.rs        # shared helpers (subdir, so it is NOT a test crate)

1
// src/lib.rs — the library under test
2
use std::collections::HashMap;
3

4
#[derive(Debug, Clone, PartialEq)]
5
pub struct Item {
6
    pub sku: String,
7
    pub price_cents: u32,
8
}
9

10
impl Item {
11
    pub fn new(sku: &str, price_cents: u32) -> Self {
12
        Item { sku: sku.to_string(), price_cents }
13
    }
14
}
15

16
#[derive(Debug, PartialEq)]
17
pub enum CartError {
18
    EmptySku,
19
    UnknownSku(String),
20
}
21

22
impl std::fmt::Display for CartError {
23
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
24
        match self {
25
            CartError::EmptySku => write!(f, "SKU must not be empty"),
26
            CartError::UnknownSku(s) => write!(f, "unknown SKU: {s}"),
27
        }
28
    }
29
}
30

31
impl std::error::Error for CartError {}
32

33
#[derive(Debug, Default)]
34
pub struct Cart {
35
    lines: HashMap<String, (Item, u32)>, // PRIVATE field
36
}
37

38
impl Cart {
39
    pub fn new() -> Self {
40
        Cart::default()
41
    }
42

43
    pub fn add(&mut self, item: Item, qty: u32) -> Result<(), CartError> {
44
        if item.sku.is_empty() {
45
            return Err(CartError::EmptySku);
46
        }
47
        let entry = self.lines.entry(item.sku.clone()).or_insert((item, 0));
48
        entry.1 += qty;
49
        Ok(())
50
    }
51

52
    pub fn quantity(&self, sku: &str) -> u32 {
53
        self.lines.get(sku).map(|(_, q)| *q).unwrap_or(0)
54
    }
55

56
    pub fn remove(&mut self, sku: &str) -> Result<(), CartError> {
57
        self.lines
58
            .remove(sku)
59
            .map(|_| ())
60
            .ok_or_else(|| CartError::UnknownSku(sku.to_string()))
61
    }
62

63
    pub fn total_cents(&self) -> u32 {
64
        self.lines.values().map(|(item, qty)| item.price_cents * qty).sum()
65
    }
66

67
    pub fn is_empty(&self) -> bool {
68
        self.lines.is_empty()
69
    }
70
}
71

72
pub fn apply_discount(total_cents: u32, percent: u8) -> u32 {
73
    let percent = percent.min(100) as u32;
74
    total_cents - (total_cents * percent / 100)
75
}

1
// tests/common/mod.rs — shared helpers, NOT a test crate of its own
2
use cart::{Cart, Item};
3

4
pub fn sample_cart() -> Cart {
5
    let mut cart = Cart::new();
6
    cart.add(Item::new("BOOK-01", 1299), 2).unwrap();
7
    cart.add(Item::new("PEN-07", 250), 4).unwrap();
8
    cart
9
}

1
// tests/cart_checkout.rs — an integration test crate
2
use cart::{apply_discount, Cart, CartError, Item};
3

4
mod common; // pulls in tests/common/mod.rs
5

6
#[test]
7
fn building_a_cart_accumulates_quantities() {
8
    let mut cart = Cart::new();
9
    cart.add(Item::new("BOOK-01", 1299), 1).unwrap();
10
    cart.add(Item::new("BOOK-01", 1299), 2).unwrap();
11
    assert_eq!(cart.quantity("BOOK-01"), 3);
12
}
13

14
#[test]
15
fn total_reflects_prices_and_quantities() {
16
    let cart = common::sample_cart();
17
    assert_eq!(cart.total_cents(), 3598);
18
}
19

20
#[test]
21
fn discount_is_applied_to_the_total() {
22
    let cart = common::sample_cart();
23
    let discounted = apply_discount(cart.total_cents(), 10);
24
    assert_eq!(discounted, 3239);
25
}
26

27
#[test]
28
fn adding_an_empty_sku_is_rejected() {
29
    let mut cart = Cart::new();
30
    let err = cart.add(Item::new("", 100), 1).unwrap_err();
31
    assert_eq!(err, CartError::EmptySku);
32
}
33

34
// A test can return `Result` and use `?` instead of `.unwrap()`.
35
#[test]
36
fn removing_a_missing_line_returns_a_result() -> Result<(), CartError> {
37
    let mut cart = common::sample_cart();
38
    cart.remove("BOOK-01")?;
39
    assert_eq!(cart.quantity("BOOK-01"), 0);
40
    Ok(())
41
}

1
// tests/cart_lifecycle.rs — a SECOND, independent test crate
2
use cart::Cart;
3

4
mod common;
5

6
#[test]
7
fn a_fresh_cart_is_empty() {
8
    let cart = Cart::new();
9
    assert!(cart.is_empty());
10
}
11

12
#[test]
13
fn removing_every_line_empties_the_cart() {
14
    let mut cart = common::sample_cart();
15
    cart.remove("BOOK-01").unwrap();
16
    cart.remove("PEN-07").unwrap();
17
    assert!(cart.is_empty());
18
}

Running cargo test compiles the library, each tests/*.rs file, and the doc-tests, then runs them all. This is the real, unedited output:

1
   Compiling cart v0.1.0 (/private/tmp/ts_rust_inttest/cart)
2
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.75s
3
     Running unittests src/lib.rs (target/debug/deps/cart-1e951a69f9a013e1)
4

5
running 0 tests
6

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

9
     Running tests/cart_checkout.rs (target/debug/deps/cart_checkout-830e111353aebe70)
10

11
running 5 tests
12
test adding_an_empty_sku_is_rejected ... ok
13
test building_a_cart_accumulates_quantities ... ok
14
test discount_is_applied_to_the_total ... ok
15
test removing_a_missing_line_returns_a_result ... ok
16
test total_reflects_prices_and_quantities ... ok
17

18
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
19

20
     Running tests/cart_lifecycle.rs (target/debug/deps/cart_lifecycle-d63887261d751300)
21

22
running 2 tests
23
test a_fresh_cart_is_empty ... ok
24
test removing_every_line_empties_the_cart ... ok
25

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

28
   Doc-tests cart
29

30
running 0 tests
31

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

Note: The current stable toolchain is Rust 1.96.0 on the 2024 edition; cargo new selects the newest edition automatically, so the layout above is what you get out of the box.

Detailed Explanation

One tests/ file = one crate. Cargo treats every .rs file directly inside tests/ as a separate integration-test crate. That is why the output above lists tests/cart_checkout.rs and tests/cart_lifecycle.rs under their own Running ... headers, each compiled into its own binary in target/debug/deps/. There is no equivalent in Jest/Vitest, where every test file shares one module graph and one process. The upside in Rust is strong isolation: a crash or a global-state mutation in one file cannot leak into another.

Integration tests see only pub. Each test crate links against your library exactly as an external user would: use cart::Cart;. The crate name comes from the name field in [package] (with dashes turned into underscores), not from a relative path. Because the test is an outside consumer, it can call Cart::new, add, total_cents, and the free function apply_discount, but it cannot read the private lines field. This is the black-box guarantee: if a type or method is not reachable from an integration test, your real users cannot reach it either.

#[test] and assertions work identically to unit tests. The #[test] attribute marks a function as a test; assert_eq!/assert! do the checking; a test that returns Result<(), E> may use ? and is considered passing when it returns Ok. Those mechanics are shared with unit tests and are covered in depth in assertions and should-panic.

The unittests src/lib.rs line with 0 tests appears because the library itself has no #[cfg(test)] module here. Cargo always offers to run the crate’s own unit tests; when there are none you simply see a zero count. That is normal, not an error.

Shared helpers go in a subdirectory. The helper sample_cart lives in tests/common/mod.rs, and each test file pulls it in with mod common;. Putting it in a common/ subdirectory (with a mod.rs) is the key: files in subdirectories are not compiled as their own test crates, so the helper is shared rather than executed as a test target. We will see what happens if you forget this in the Pitfalls section.

Why the test calls .unwrap() in helpers but ? in a test body. Inside sample_cart, .unwrap() is fine — if setup fails, the test should abort loudly. Inside a #[test] -> Result<...> body, returning the error via ? produces a clean failure report instead of a panic backtrace. Both are idiomatic; choose based on whether the failing call is setup or the thing under test.

Key Differences

Aspect	TypeScript (Jest/Vitest)	Rust integration tests
Location	Anywhere; commonly `tests/` or `__tests__/`	A top-level `tests/` directory only
Compilation unit	One shared module graph, one process	Each `tests/*.rs` is its own crate + binary
What’s visible	Everything (privates reachable via `as any`)	The crate’s public API only
How the module is imported	Relative path: `../src/cart`	Crate name: `use cart::...`
Shared setup file	A regular imported file	A `tests/common/mod.rs` in a subdirectory
Isolation between files	Shared globals/mocks unless reset	Hard process/crate isolation by default
Parallelism	Per-file workers (configurable)	Tests run in parallel threads by default
Library vs binary	No distinction	Only library crates are integration-testable directly

The most consequential difference is the public-API constraint. In TypeScript, private is advisory and erased at runtime, so a test can reach internals when it wants to. Rust’s integration tests are compiled against the crate boundary, so the visibility rules are enforced by the compiler. If you need to test a private function, that belongs in a unit test inside the module (see test-organization).

Note: Integration tests can only target a library crate. A crate with just src/main.rs exposes no library API, so use yourbin::... will not resolve. The common production pattern is a thin src/main.rs that calls into a src/lib.rs; the library is integration-tested, and the binary is tested by running it (shown in the Real-World Example below).

Common Pitfalls

Pitfall 1: A flat helper file in `tests/` gets run as a test

If you put shared helpers in tests/helpers.rs (a flat file, not a subdirectory), Cargo compiles it as its own integration-test crate. It contains no #[test] functions, so you get a confusing empty run:

1
// tests/helpers.rs — WRONG place for a shared helper
2
use cart::{Cart, Item};
3

4
pub fn sample_cart() -> Cart {
5
    let mut cart = Cart::new();
6
    cart.add(Item::new("BOOK-01", 1299), 2).unwrap();
7
    cart
8
}

Running it shows the helper file masquerading as a test target with nothing to run:

1
     Running tests/helpers.rs (target/debug/deps/helpers-58b7202b39b88064)
2

3
running 0 tests
4

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

Fix: move the helper to tests/common/mod.rs and pull it in with mod common;. Files in subdirectories are not treated as test crates.

Pitfall 2: Trying to reach a private item

Coming from TypeScript, you might expect a test to touch internals “just this once.” Add a private function to the library and call it from an integration test:

1
// in src/lib.rs
2
fn round_to_nearest_dollar(cents: u32) -> u32 { // private!
3
    ((cents + 50) / 100) * 100
4
}

1
#[test]
2
fn cannot_reach_private_fn() {
3
    // does not compile (error[E0603]: function is private)
4
    let _ = cart::round_to_nearest_dollar(1250);
5
}

The compiler stops you with the real error:

1
error[E0603]: function `round_to_nearest_dollar` is private
2
 --> tests/private_probe.rs:4:19
3
  |
4
4 |     let _ = cart::round_to_nearest_dollar(1250);
5
  |                   ^^^^^^^^^^^^^^^^^^^^^^^ private function
6
  |
7
note: the function `round_to_nearest_dollar` is defined here
8
 --> src/lib.rs:79:1
9
  |
10
79 | fn round_to_nearest_dollar(cents: u32) -> u32 {
11
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Fix: either make the item pub (if it truly is part of the API), or test it from a unit test inside the module where private access is allowed.

Pitfall 3: Importing by relative path instead of crate name

There is no use crate::... or use super::... reaching out of tests/ into src/ — an integration test is a separate crate. Write use cart::Cart; (the package name), the same way an external dependency would. Newcomers often try use super::cart::Cart; or a mod pointing at ../src, both of which fail to resolve.

Pitfall 4: Expecting `console.log`-style output by default

Just like Vitest hides logs from passing tests, Rust captures stdout/stderr and only shows it for failing tests. If you want to see prints from passing tests, run cargo test -- --nocapture. (The -- separates Cargo’s arguments from the test harness’s.)

Pitfall 5: Forgetting that integration tests need a library target

If your crate is binary-only, cargo test will still run the binary’s unit tests, but use yourbin::... in tests/ won’t compile because there is no library to link. The fix is to extract logic into src/lib.rs.

Best Practices

Group by feature, not by function. One file per user-facing workflow (tests/cart_checkout.rs, tests/auth_flow.rs) reads better than one giant tests/lib.rs. Because each file is its own crate, this also improves parallelism.
Keep shared setup in tests/common/mod.rs. Expose small pub fn constructors there. For heavier setup (temp directories, fixtures, RAII teardown), see test-fixtures.
Treat integration tests as your API’s first real consumer. If a test is awkward to write because the public API is clumsy, that is feedback about the API, not the test.
Use Result-returning tests with ? for flows that involve fallible setup steps; reserve .unwrap() for “this must succeed or the test is meaningless” setup.
Pin dev-only crates under [dev-dependencies]. Things like assert_cmd, predicates, or tempfile should never end up in your published dependency graph. Add them with cargo add --dev <crate> (the add subcommand has been built into Cargo since 1.62 — no cargo-edit needed).
Select a single file with --test. cargo test --test cart_checkout runs only that integration-test crate; append a name substring to filter further, e.g. cargo test --test cart_checkout total.
Do not duplicate unit-test coverage. Integration tests verify the contract; private-logic edge cases belong in unit tests. See test-organization for where each kind lives.

Real-World Example

A production crate usually ships a library plus a thin binary. The library is integration-tested through its public API; the binary is integration-tested by running the compiled program and asserting on its exit code and output. The assert_cmd and predicates crates make the latter ergonomic — they are the Rust analog of spawning your CLI in a Jest test and checking stdout.

1
[package]
2
name = "greet"
3
version = "0.1.0"
4
edition = "2024"
5

6
[dev-dependencies]
7
assert_cmd = "2.2.2"
8
predicates = "3.1.4"

1
// src/main.rs — the binary under test
2
use std::env;
3
use std::process::ExitCode;
4

5
fn main() -> ExitCode {
6
    let args: Vec<String> = env::args().skip(1).collect();
7
    match args.first().map(String::as_str) {
8
        Some(name) if !name.is_empty() => {
9
            println!("Hello, {name}!");
10
            ExitCode::SUCCESS
11
        }
12
        _ => {
13
            eprintln!("error: expected a name argument");
14
            ExitCode::from(2)
15
        }
16
    }
17
}

1
// tests/cli.rs — black-box test of the actual binary
2
use assert_cmd::Command;
3
use predicates::prelude::*;
4

5
#[test]
6
fn greets_a_named_user() {
7
    let mut cmd = Command::cargo_bin("greet").unwrap();
8
    cmd.arg("Ada")
9
        .assert()
10
        .success()
11
        .stdout(predicate::str::contains("Hello, Ada!"));
12
}
13

14
#[test]
15
fn fails_without_a_name() {
16
    let mut cmd = Command::cargo_bin("greet").unwrap();
17
    cmd.assert()
18
        .failure()
19
        .code(2)
20
        .stderr(predicate::str::contains("expected a name"));
21
}

Command::cargo_bin("greet") locates and runs the freshly compiled binary; the .assert() builder then checks the exit status and matches stdout/stderr against predicates combinators. Running cargo test --test cli produces this real output:

1
   Compiling greet v0.1.0 (/private/tmp/ts_rust_clitest/greet)
2
    Finished `test` profile [unoptimized + debuginfo] target(s) in 6.63s
3
     Running tests/cli.rs (target/debug/deps/cli-cd6dde0ca03346ee)
4

5
running 2 tests
6
test greets_a_named_user ... ok
7
test fails_without_a_name ... ok
8

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

This is genuine black-box testing: the test knows nothing about the program’s internals, only its command-line contract — the closest Rust equivalent to spawning your built CLI in a Jest/Vitest test and asserting on its output.

Exercises

Exercise 1: Your first integration test

Difficulty: Beginner

Objective: Create a library crate and verify its public API from tests/.

Instructions: Run cargo new --lib slugify. In src/lib.rs, write pub fn slugify(input: &str) -> String that lowercases the text, replaces every run of non-alphanumeric characters with a single -, and trims leading/trailing -. Add tests/slugify.rs with at least two #[test] functions that call slugify::slugify(...) and assert on the results. Run cargo test.

Solution

1
pub fn slugify(input: &str) -> String {
2
    let mut out = String::new();
3
    let mut prev_dash = true; // start "true" so leading separators are dropped
4
    for ch in input.chars() {
5
        if ch.is_ascii_alphanumeric() {
6
            out.extend(ch.to_lowercase());
7
            prev_dash = false;
8
        } else if !prev_dash {
9
            out.push('-');
10
            prev_dash = true;
11
        }
12
    }
13
    while out.ends_with('-') {
14
        out.pop();
15
    }
16
    out
17
}

1
use slugify::slugify;
2

3
#[test]
4
fn collapses_separators_and_lowercases() {
5
    assert_eq!(slugify("Hello, World!"), "hello-world");
6
}
7

8
#[test]
9
fn trims_edges_and_runs() {
10
    assert_eq!(slugify("  ***Rust  &  TS*** "), "rust-ts");
11
}

Output:

1
running 2 tests
2
test collapses_separators_and_lowercases ... ok
3
test trims_edges_and_runs ... ok
4

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

Difficulty: Intermediate

Objective: Use a tests/common/mod.rs helper from more than one integration-test file without it being run as a test.

Instructions: Starting from a cargo new --lib kv crate, implement a tiny pub struct Store backed by a HashMap<String, String> with pub fn new(), pub fn set(&mut self, k: &str, v: &str), and pub fn get(&self, k: &str) -> Option<&str>. Add tests/common/mod.rs exposing pub fn seeded() -> Store that inserts two known keys. Then write two test files (tests/reads.rs and tests/writes.rs), each declaring mod common; and using common::seeded(). Confirm cargo test lists two separate test crates and zero stray empty ones.

Solution

1
use std::collections::HashMap;
2

3
#[derive(Debug, Default)]
4
pub struct Store {
5
    map: HashMap<String, String>,
6
}
7

8
impl Store {
9
    pub fn new() -> Self {
10
        Store::default()
11
    }
12

13
    pub fn set(&mut self, k: &str, v: &str) {
14
        self.map.insert(k.to_string(), v.to_string());
15
    }
16

17
    pub fn get(&self, k: &str) -> Option<&str> {
18
        self.map.get(k).map(String::as_str)
19
    }
20
}

1
use kv::Store;
2

3
pub fn seeded() -> Store {
4
    let mut s = Store::new();
5
    s.set("lang", "rust");
6
    s.set("year", "2026");
7
    s
8
}

1
mod common;
2

3
#[test]
4
fn reads_seeded_values() {
5
    let s = common::seeded();
6
    assert_eq!(s.get("lang"), Some("rust"));
7
    assert_eq!(s.get("missing"), None);
8
}

1
use kv::Store;
2

3
mod common;
4

5
#[test]
6
fn writes_override_existing_values() {
7
    let mut s = common::seeded();
8
    s.set("lang", "ferris");
9
    assert_eq!(s.get("lang"), Some("ferris"));
10
}
11

12
#[test]
13
fn fresh_store_is_distinct_from_seeded() {
14
    let empty = Store::new();
15
    assert_eq!(empty.get("lang"), None);
16
}

Output (test-crate headers only):

1
     Running tests/reads.rs (target/debug/deps/reads-...)
2
running 1 test
3
test reads_seeded_values ... ok
4

5
     Running tests/writes.rs (target/debug/deps/writes-...)
6
running 2 tests
7
test fresh_store_is_distinct_from_seeded ... ok
8
test writes_override_existing_values ... ok

Because common lives in a subdirectory, there is no Running tests/common/mod.rs line — exactly what we want.

Exercise 3: Black-box test a binary’s exit code

Difficulty: Advanced

Objective: Test a compiled binary end-to-end with assert_cmd, asserting on both success and failure paths.

Instructions: Create cargo new adder. The program reads two integer arguments, prints their sum on success, and exits with code 2 plus a stderr message if an argument is missing or not a number. Add assert_cmd and predicates as dev-dependencies (cargo add --dev assert_cmd predicates) and write tests/cli.rs with one test for a valid sum and one for a parse failure.

Solution

1
use std::env;
2
use std::process::ExitCode;
3

4
fn main() -> ExitCode {
5
    let nums: Vec<String> = env::args().skip(1).collect();
6
    if nums.len() != 2 {
7
        eprintln!("error: expected exactly two integers");
8
        return ExitCode::from(2);
9
    }
10
    let mut sum: i64 = 0;
11
    for n in &nums {
12
        match n.parse::<i64>() {
13
            Ok(v) => sum += v,
14
            Err(_) => {
15
                eprintln!("error: '{n}' is not an integer");
16
                return ExitCode::from(2);
17
            }
18
        }
19
    }
20
    println!("{sum}");
21
    ExitCode::SUCCESS
22
}

1
# Cargo.toml (the relevant part)
2
[dev-dependencies]
3
assert_cmd = "2.2.2"
4
predicates = "3.1.4"

1
use assert_cmd::Command;
2
use predicates::prelude::*;
3

4
#[test]
5
fn adds_two_integers() {
6
    Command::cargo_bin("adder")
7
        .unwrap()
8
        .args(["19", "23"])
9
        .assert()
10
        .success()
11
        .stdout(predicate::str::contains("42"));
12
}
13

14
#[test]
15
fn rejects_non_integer_input() {
16
    Command::cargo_bin("adder")
17
        .unwrap()
18
        .args(["19", "oops"])
19
        .assert()
20
        .failure()
21
        .code(2)
22
        .stderr(predicate::str::contains("not an integer"));
23
}

Output:

1
running 2 tests
2
test adds_two_integers ... ok
3
test rejects_non_integer_input ... ok
4

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

Integration Tests: The tests/ Directory and Black-Box Testing

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Key Differences

Common Pitfalls

Pitfall 1: A flat helper file in tests/ gets run as a test

Pitfall 2: Trying to reach a private item

Pitfall 3: Importing by relative path instead of crate name

Pitfall 4: Expecting console.log-style output by default

Pitfall 5: Forgetting that integration tests need a library target

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Your first integration test

Exercise 2: Share setup across two test files

Exercise 3: Black-box test a binary’s exit code

Integration Tests: The `tests/` Directory and Black-Box Testing

Pitfall 1: A flat helper file in `tests/` gets run as a test

Pitfall 4: Expecting `console.log`-style output by default