How do I display only test classes where tests exist?

[kpreid]

@fairy

The contents of Cargo.toml:

[package]
name = "hello_cargo"
version = "0.1.0"
edition = "2024"

[dependencies]
main = "0.1.0"

You'll want to delete the line main = "0.1.0". It’s referring to main on crates.io, which isn't particularly harmful but is a basically empty library that doesn’t do anything you want.

@fairy

A crate can come in one of two forms: a binary crate or a library crate. Binary crates are programs you can compile to an executable that you can run, such as a command line program or a server. Each must have a function called main that defines what happens when the executable runs. All the crates we’ve created so far have been binary crates.

My aim: So I though main.rs and main1.rs both with main()would be different crates so how can I make them different crates…

If you want multiple binary crates, then you should organize them differently, like this:

src/
    bin/                  # this name is where Cargo looks for additional crates 
        mybin1/           # this is your choice of name
            main.rs       # This will be compiled as the crate root for mybin1
        mybin2/           # this is your choice of name
            main.rs       # This will be compiled as the crate root for mybin1

The point of having multiple binary crates in a package is to compile them into multiple, distinct executable programs. If you don't want to make multiple programs that share some parts, you don't need multiple binary crates.

If you want multiple library crates, you need to create an additional package (directory with Cargo.toml file). Each package may only have at most one library crate (but can have any number of binary crates in addition).

The point of having library crates is to produce libraries that other programs can use. If you don't want to share code for others to use, or share code between multiple binary crates you are working on, then you don't need any library crates.^[1]

… and if the excerpt from the book is not an exhaustive definition for crates what is one?

A crate is “the thing that rustc compiles when run once”. Multiple crates mean rustc is being run more than once. The compilation can produce either a compiled library for use by further crate compilations, or a compiled binary (executable) that you can run standalone. There are a number of things in the language that care about what crate code is in, like trait coherence and paths that start with crate::.

Broadly speaking, every project should be a single crate until you have a specific reason to split it into more than one crate. Multiple crates add complexity (and can either increase or decrease total build time, depending on the choice of split).

I ran simple unit tests for main.rs and its submodules and wanted to run an integration test using different crates (which I thought where different crates). Thats why I test functions from main and main1.

The “integration test” feature of Cargo is intended to be used for two use cases:

• Testing a library crate by using its public functions.
• Testing a binary crate by running the program and seeing what it does.

Testing functions in the code of a binary crate is neither of those things — to write that kind of test, you must write the tests in the crate's own source code in src/, not in tests/. That's the only way the functions will be reachable.

---

1. There are more reasons to add library crates, but they are more complex. ↩︎