Repository navigation
DOC: describe how to create a test environment with tox - #15878
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
We had a lot of discussion in #10394 about this, which I did not revisit as somehow I thought this was the elegant better solution that was then not possible, instead of the one I already tried to add at that time. Anyway, if there is a better solution now, happy to adopt it. But if not, let's get this time-saver in... |
|
With tox 4 |
Because it is way slower. I just happened to have an enviroment set up: 10 s for not even running any test (I don't know how to select just one) vs 1 s matters if you are trying to debug something. |
| tox -e test --develop --notest | ||
| source .tox/test/bin/activate |
There was a problem hiding this comment.
I'd suggest documenting using all dependencies by default in development. The incremental cost is low and running all those tests locally is good.
| tox -e test --develop --notest | |
| source .tox/test/bin/activate | |
| tox -e test-alldeps --develop --notest | |
| source .tox/test-alldeps/bin/activate |
There was a problem hiding this comment.
BTW I tested this from a clean Python 3.11 conda env and it worked well and is fast. It only requires installing tox, nothing more beyond these commands, so I think that's a win.
I have an idea to write a Quickstart section to provide one simple workflow as a prelude to the rest of the detailed options here, but getting this PR merged will be a big step forward.
There was a problem hiding this comment.
Yes, makes sense. Indeed, I often end up doing pip install ipython to do some more interactive debugging, and this will just pull that in too.
| and this works for ``.rst`` files too:: | ||
| or:: | ||
|
|
||
| pytest astropy/units/tests/test_quantity.py::TestQuantityCreation::test_float_dtype_promotion |
There was a problem hiding this comment.
This is fine but in practice I would always do something shorter like pytest astropy/units -k float_dtype.
Maybe combine all these into examples in a single block of examples:
You can also specify a single directory, a file (Python or ``.rst`` doc file), or a specific test
to check from the commandline, e.g.::
pytest astropy/modeling
pytest astropy/wcs/tests/test_wcs.py
pytest astropy/units -k float_dtype_promotion
pytest astropy/units/tests/test_quantity.py::TestQuantityCreation::test_float_dtype_promotion
pytest astropy/wcs/index.rst
There was a problem hiding this comment.
The long form has the advantage of tab completion for just the file, and copy & paste from pytest output... But your suggestion of a slew of examples is best!
There was a problem hiding this comment.
pytest has documentation about test selection and there is no reason we shouldn't link to that and only highlight the differences here. As far as I can tell there are two differences:
- Thanks to
pytest-doctestplusit is possible to run tests in docstrings of all.pyfiles and tests in all.rstfiles. - Thanks to
pytest-filter-subpackageit is possible to run all tests related to a package (e.g.wcs) withpytest -P wcs, whereas without the plugin the equivalent invocation would bepytest {astropy,docs}/wcs.
There was a problem hiding this comment.
True, but that the page linked to is substantially longer than the simple list yet does not provide much beyond it. In these development docs, I feel we should just help people get going.
That said, obviously can include the link...
There was a problem hiding this comment.
It would also be good to link https://docs.pytest.org/en/stable/how-to/cache.html
There was a problem hiding this comment.
Thanks! I've pushed an extra commit with both links (learned about -k and --lf now...). I added [skip ci] to the last commit to avoid running all tests again when the docs will do, but obviously fine to squash the commits.
b8b363c to
0126518
Compare
|
@taldcroft - thanks! I pushed a new version with your changes. |
This is great! I previously couldn't find the docs but now I see. Cool. |
|
@pllim - would you be able to merge? I used |
|
Sure thing. Sorry for the delayed response. I usually don't work in the weekends (if I can help it). |
|
@pllim - and you shouldn't! I didn't mean my message to convey any sense of hurry - just that I couldn't do the merge myself (and that I don't presume you would be looking out for approved PRs stalled because of |
Add a description to the test guide with a handy way to use
toxto create a virtual environment with all the test packages nicely set up. As asked by @taldcroft in #10303 (comment)