improve explanation of placing tests in separate file (#1721)

Co-authored-by: Yuki Okushi <jtitor@2k36.org>
This commit is contained in:
Tshepang Mbambo 2023-07-08 04:54:25 +02:00 committed by GitHub
parent 6d5b3db86f
commit b10654acbf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 7 deletions

View File

@ -43,9 +43,9 @@ 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. However, unit tests and integration tests can also be used as needed.
Almost all of the compiler packages have doctests disabled. Almost all of the compiler packages have doctests disabled.
The standard library and compiler always place all unit tests in a separate `tests` file All standard library and compiler unit tests are placed in separate `tests` file
(this is enforced in [tidy][tidy-unit-tests]). (which 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. This ensures that when the test file is changed, the crate does not need to be recompiled.
For example: For example:
```rust,ignore ```rust,ignore
@ -53,10 +53,9 @@ For example:
mod tests; mod tests;
``` ```
If it wasn't done this way, and the tests were placed in the same file as the source, If it wasn't done this way,
then changing or adding a test would cause the crate you are working on to be recompiled. and you were working on something like `core`,
If you were working on something like `core`, that would require recompiling the entire standard library, and the entirety of `rustc`.
then 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: `./x test` includes some CLI options for controlling the behavior with these tests: