Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve explanation of placing tests in separate file #1721

Merged
merged 2 commits into from
Jul 8, 2023
Merged

improve explanation of placing tests in separate file #1721

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d675461
improve explanation of placing tests in separate file
tshepang Jul 5, 2023
af4ab0c
Update src/tests/intro.md
JohnTitor Jul 8, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions src/tests/intro.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,20 +43,19 @@ The standard library relies very heavily on documentation tests to cover its fun
However, unit tests and integration tests can also be used as needed.
Almost all of the compiler packages have doctests disabled.

The standard library and compiler always place all unit tests in a separate `tests` file
(this is enforced in [tidy][tidy-unit-tests]).
This approach ensures that when the test file is changed, the crate does not need to be recompiled.
All standard library and compiler unit tests are placed in separate `tests` file
(which is enforced in [tidy][tidy-unit-tests]).
This ensures that when the test file is changed, the crate does not need to be recompiled.
For example:

```rust,ignore
#[cfg(test)]
mod tests;
```

If it wasn't done this way, and the tests were placed in the same file as the source,
then changing or adding a test would cause the crate you are working on to be recompiled.
If you were working on something like `core`,
then that would require recompiling the entire standard library, and the entirety of `rustc`.
If it wasn't done this way,
and you were working on something like `core`,
that would require recompiling the entire standard library, and the entirety of `rustc`.

`./x test` includes some CLI options for controlling the behavior with these tests:

Expand Down