Cargo, Testing & Tooling

Core concepts

1. Cargo.toml: Dependencies with semver; features flags for optional functionality. — Cargo manifest
2. Workspace: Multiple crates in one repo — shared target/ cache. — The Rust Book: Cargo workspaces
3. Tests: #[test] functions; assert_eq!, should_panic. — The Rust Book: Writing tests
4. Clippy: cargo clippy — lints for idiomatic Rust. — Clippy
5. rustfmt: Enforced formatting — no style debates in review. — rustfmt

pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn adds() {
        assert_eq!(add(2, 2), 4);
    }
}

Concept videos

YouTube lessons for these topics. On a large screen they open in the reading panel next to the roadmap, same as the article links on each core concept.

• Clippy — Clippy & Rust tooling (Jon Gjengset)

Explanation

Cargo is the project operating system for Rust — dependencies, builds, tests, docs, and publish flows share one tool.

Cargo.toml

Manifest lists crate name, version, edition, dependencies with semver ranges. Feature flags toggle optional modules (serde, async) so consumers compile only what they need.

Workspace

Monorepos with multiple crates share one target/ directory — faster builds, consistent versions. Common pattern: binary crate + library crate side by side.

Tests

Unit tests live beside code in mod tests; integration tests in /tests behave like external consumers. should_panic documents expected failure cases — ownership of errors, not surprises.

Clippy

Clippy suggests idiomatic fixes — needless borrows, inefficient clones, suspicious patterns. Run in CI to teach Rust style continuously.

rustfmt

Automatic formatting keeps diffs focused. Pair fmt + clippy + test in CI for a baseline quality gate before human review.

What Is It?

Cargo.toml declares dependencies, features, and profiles (dev/release).

Unit tests sit in #[cfg(test)] modules; integration tests are separate crates linking your library.

clippy lints idioms; rustfmt enforces style.

Why Should I Care?

Rust culture expects tests and clippy clean in CI before merge.

Benchmarks (criterion) guide perf work on hot paths.

Real World Analogy

Cargo test is a pit crew checklist before a race — fast unit tests in-module, integration tests in tests/ like a full track lap.

Visual Mental Model

cargo test
  |-- unit (in file)
  |-- integration (tests/)

Beginner Explanation

Use cargo test, clippy, and rustfmt in every repo. Integration tests live under tests/ and see public API only.

Smallest Possible Example

#[cfg(test)]
mod tests {
    #[test]
    fn adds() { assert_eq!(2 + 2, 4); }
}

Common Mistakes

❌ Testing private functions instead of public behavior.

Integration tests document the API surface users rely on.

❌ Ignoring dev-dependencies vs dependencies.

Test-only crates belong in [dev-dependencies].

❌ Skipping cargo clippy -- -D warnings in CI.

Clippy catches footguns rustc alone misses.

Real Project Example

Open source Rust on GitHub runs cargo test + clippy in Actions by default template.

Rust-analyzer in VS Code/Cursor uses Cargo metadata for jump-to-def.

Build This Mini Project

Add one unit test and one integration test to a crate; wire cargo clippy and cargo fmt --check locally.

Interview Question

Where do integration tests go?

In the tests/ directory at crate root — each file is a separate crate that imports your library like external users would.

Key Takeaways

• Cargo orchestrates build/test/lint.
• Unit vs integration test placement matters.
• clippy + fmt are team defaults.
• Lock dependencies for reproducible builds.

Resources

• Cargo book
• Clippy lints

The 60-second story

A workshop with more than one bench. Cargo.toml is the clipboard on the wall: which parts you depend on, which optional features are switched on, which versions you are willing to accept. Features are extra attachments you do not bolt on unless today’s job needs them. That keeps the default build from dragging a welding rig into a watch-repair job.

A workspace is several benches sharing one scrap bin, the target/ directory. You are not rebuilding the world once per crate when they live in one repo. You still get separate crates so a parser does not silently depend on the HTTP server’s secrets.

Tests are trial cuts before you hand the piece to a customer. #[test] marks a function as a trial. assert_eq! says the measurement must match. should_panic says this cut is supposed to fail loudly. You run them with the same manager that builds the shop, cargo test, so “how do I run tests” is not a second religion.

Clippy is the senior who walks the bench after you and says “this pattern rusts.” It is not formatting. It is “you cloned when you could have borrowed” and “this unwrap will bite you.” rustfmt is the other senior who only cares that the tools hang straight. Let them split the job. Humans are bad at both when they are also trying to design the joint.

Map the wall.

• Cargo.toml is the clipboard of parts and feature flags.
• A workspace is several benches, one scrap bin.
• #[test] is a trial cut.
• Clippy is the “this will rust” review.
• rustfmt is the straight pegboard.
• CI is the door that will not open if either senior is unhappy.

#[test]
fn adds() {
    assert_eq!(2 + 2, 4);
}

Tiny, and it still documents the contract. When the function grows, the trial stays. That is the point of keeping tests next to the code instead of in a slideshow.

Cargo’s test and lint tools exist because a language that is strict at compile time still cannot see that you tested the happy path only in your head. Clippy exists because the compiler accepts a lot of code that is legal and clumsy. Format-on-save exists so review comments can be about the joint.

Mental model: a clipboard, trial cuts, and two seniors with different jobs. One senior talks about rust. The other talks about alignment. Do not make your teammates be both.

You have the page if you can say where dependencies are declared, how a test is marked, and why Clippy and rustfmt are not the same button.