Skip to content

Commit 5c06f3c

Browse files
authored
docs: Add how to run tests in development (#1698)
* Add docs for how to run tests in development * Update the docs to use nox primarily and not require CIBW_PLATFORM * Reorganise this file
1 parent e2a0839 commit 5c06f3c

File tree

1 file changed

+74
-22
lines changed

1 file changed

+74
-22
lines changed

docs/contributing.md

+74-22
Original file line numberDiff line numberDiff line change
@@ -12,8 +12,7 @@ If you have an idea for a modification or feature, it's probably best to raise a
1212

1313
Everyone contributing to the cibuildwheel project is expected to follow the [PSF Code of Conduct](https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md).
1414

15-
Design Goals
16-
------------
15+
## Design Goals
1716

1817
- `cibuildwheel` should wrap the complexity of wheel building.
1918
- The user interface to `cibuildwheel` is the build script (e.g. `.travis.yml`). Feature additions should not increase the complexity of this script.
@@ -33,41 +32,94 @@ We're not responsible for errors in those tools, for fixing errors/crashes there
3332

3433
So, if we can, I'd like to improve the experience on errors as well. In [this](https://github.com/pypa/cibuildwheel/issues/139) case, it takes a bit of knowledge to understand that the Linux builds are happening in a different OS via Docker, that the linked symbols won't match, that auditwheel will fail because of this. A problem with how the tools fit together, instead of the tools themselves.
3534

36-
Maintainer notes
37-
----------------
35+
## Development
3836

39-
### Nox support
37+
### Running the tests
4038

41-
Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is a slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
39+
When making a change to the codebase, you can run tests locally for quicker feedback than the CI runs on a PR. You can [run them directly](#making-a-venv), but the easiest way to run tests is using [nox](https://nox.thea.codes/).
4240

43-
Install [nox](https://nox.thea.codes); homebrew is recommend on macOS, otherwise, pipx is a great choice - in fact, you can use `pipx run nox` and avoid installing completely.
41+
You can run all the tests locally by doing:
4442

45-
You can see a list of sessions by typing `nox -l`; here are a few common ones:
43+
```bash
44+
nox -s tests
45+
```
4646

47-
```console
48-
nox -s lint # Run the linters (default)
49-
nox -s tests # Run the tests (default)
50-
nox -s docs -- serve # Build and serve the documentation
51-
nox -s build # Make SDist and wheel
47+
However, because this takes a while, you might prefer to be more specific.
48+
49+
#### Unit tests
50+
51+
To run the project's unit tests, do:
52+
53+
```bash
54+
nox -s tests -- unit_test
5255
```
5356

54-
More advanced users can run the update scripts. `update_pins` should work directly, but `update_constraints` needs all versions of Python installed. If you don't want to do that locally, a fast way to run it to use docker to run nox:
57+
There are a few custom options to enable different parts of the test suite - check `nox -s tests -- unit_test --help` for details.
5558

56-
```console
57-
docker run --rm -itv $PWD:/src -w /src quay.io/pypa/manylinux_2_24_x86_64:latest pipx run nox -s update_constraints
59+
If you're calling this a lot, you might consider using the `-r` or `-R` arguments to nox to make it a bit faster. This calls pytest under the hood, so to target a specific test, use pytest's `-k` option after the `--` above to select a specific test.
60+
61+
#### Integration tests
62+
63+
To run the project's integration tests, do:
64+
65+
```bash
66+
nox -s tests -- test
5867
```
5968

60-
### Local testing
69+
The integration test suite is big - it can take more than 30 minutes to run the whole thing.
6170

62-
You should run:
71+
Because it takes such a long time, normally you'd choose specific tests to run locally, and rely on the project's CI for the rest. Use pytest's `-k` option to choose specific tests. You can pass a test name or a filename, it'll run everything that matches.
6372

64-
```console
65-
python3 -m venv venv
66-
. venv/bin/activate
73+
```bash
74+
nox -s tests -- test -k <test_name_or_filename>
75+
# e.g.
76+
nox -s tests -- test -k before_build
77+
```
78+
79+
A few notes-
80+
81+
- Because they run inside a container, Linux tests can run on all platforms where Docker is installed, so they're convenient for running integration tests locally. Set CIBW_PLATFORM to do this: `CIBW_PLATFORM=linux nox -s tests -- test`.
82+
83+
- Running the macOS integration tests requires _system installs_ of Python from python.org for all the versions that are tested. We won't attempt to install these when running locally, but you can do so manually using the URL in the error message that is printed when the install is not found.
84+
85+
#### Making a venv
86+
87+
More advanced users might prefer to invoke pytest directly-
88+
89+
```bash
90+
python3 -m venv .venv
91+
source .venv/bin/activate
6792
pip install -e .[dev]
93+
# run the unit tests
94+
pytest unit_test
95+
# run the whole integration test suite
96+
pytest test
97+
# run a specific integration test
98+
pytest test -k test_build_frontend_args
99+
# run a specific integration test on a different platform
100+
CIBW_PLATFORM=linux pytest test -k test_build_frontend_args
101+
```
102+
103+
### Linting, docs
104+
105+
Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is a slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
106+
107+
You can see a list of sessions by typing `nox -l`; here are a few common ones:
108+
109+
```console
110+
nox -s lint # Run the linters (default)
111+
nox -s tests [-- PYTEST-ARGS] # Run the tests (default)
112+
nox -s docs -- serve # Build and serve the documentation
113+
nox -s build # Make SDist and wheel
114+
```
115+
116+
More advanced users can run the update scripts. `update_pins` should work directly, but `update_constraints` needs all versions of Python installed. If you don't want to do that locally, a fast way to run it to use docker to run nox:
117+
118+
```console
119+
docker run --rm -itv $PWD:/src -w /src quay.io/pypa/manylinux_2_24_x86_64:latest pipx run nox -s update_constraints
68120
```
69121

70-
To prepare a development environment.
122+
## Maintainer notes
71123

72124
### Testing sample configs
73125

0 commit comments

Comments
 (0)