# Running tests
<!-- toc -->
You can run the entire test collection using `x`. But note that running the
*entire* test collection is almost never what you want to do during local
development because it takes a really long time. For local development, see the
subsection after on how to run a subset of tests.
<div class="warning">
Running plain `./x test` will build the stage 1 compiler and then run the whole
test suite. This not only include `tests/`, but also `library/`, `compiler/`,
`src/tools/` package tests and more.
You usually only want to run a subset of the test suites (or even a smaller set
of tests than that) which you expect will exercise your changes. PR CI exercises
a subset of test collections, and merge queue CI will exercise all of the test
collection.
</div>
```text
./x test
```
The test results are cached and previously successful tests are `ignored` during
testing. The stdout/stderr contents as well as a timestamp file for every test
can be found under `build/<target-tuple>/test/` for the given
`<target-tuple>`. To force-rerun a test (e.g. in case the test runner fails to
notice a change) you can use the `--force-rerun` CLI option.
> **Note on requirements of external dependencies**
>
> Some test suites may require external dependencies. This is especially true of
> debuginfo tests. Some debuginfo tests require a Python-enabled gdb. You can
> test if your gdb install supports Python by using the `python` command from
> within gdb. Once invoked you can type some Python code (e.g. `print("hi")`)
> followed by return and then `CTRL+D` to execute it. If you are building gdb
> from source, you will need to configure with
> `--with-python=<path-to-python-binary>`.
## Running a subset of the test suites
When working on a specific PR, you will usually want to run a smaller set of
tests. For example, a good "smoke test" that can be used after modifying rustc
to see if things are generally working correctly would be to exercise the `ui`
test suite ([`tests/ui`]):
```text
./x test tests/ui
```
Of course, the choice of test suites is
somewhat arbitrary, and may not suit the task you are doing. For example, if you
are hacking on debuginfo, you may be better off with the debuginfo test suite:
```text
./x test tests/debuginfo
```
If you only need to test a specific subdirectory of tests for any given test
suite, you can pass that directory as a filter to `./x test`:
```text
./x test tests/ui/const-generics
```
> **Note for MSYS2**
>
> On MSYS2 the paths seem to be strange and `./x test` neither recognizes
> `tests/ui/const-generics` nor `tests\ui\const-generics`. In that case, you can
> workaround it by using e.g. `./x test ui
> --test-args="tests/ui/const-generics"`.
Likewise, you can test a single file by passing its path:
```text
./x test tests/ui/const-generics/const-test.rs
```
`x` doesn't support running a single tool test by passing its path yet. You'll
have to use the `--test-args` argument as described
[below](#running-an-individual-test).
```text
./x test src/tools/miri --test-args tests/fail/uninit/padding-enum.rs
```
### Run only the tidy script
```text
./x test tidy
```
### Run tests on the standard library
```text
./x test --stage 0 library/std
```
Note that this only runs tests on `std`; if you want to test `core` or other
crates, you have to specify those explicitly.
### Run the tidy script and tests on the standard library
```text
./x test --stage 0 tidy library/std
```
### Run tests on the standard library using a stage 1 compiler
```text
./x test --stage 1 library/std
```
By listing which test suites you want to run,
you avoid having to run tests for components you did not change at all.
<div class="warning">
Note that bors only runs the tests with the full stage 2 build; therefore, while
the tests **usually** work fine with stage 1, there are some limitations.
</div>
### Run all tests using a stage 2 compiler
```text
./x test --stage 2
```
<div class="warning">
You almost never need to do this; CI will run these tests for you.