Repository navigation
Update testing documentation to reflect plugin changes - #6811
Conversation
|
Hi there @drdavella 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃. Everything looks good from my point of view! 👍 If there are any issues with this message, please report them here. |
|
|
||
| The test suite can be run directly from the native ``pytest`` command. In this | ||
| case, it is important for developers to be aware that they must manually | ||
| rebuild any extensions by running ``setup.py build`` before testing. |
There was a problem hiding this comment.
This should be setup.py build_ext.
c1b8c64 to
e5fc0c1
Compare
| As of Astropy 3.0, the dependencies used by the Astropy test runner are | ||
| provided by a separate package called ``pytest-astropy``. This package provides | ||
| the ``pytest`` dependency itself, in addition to several ``pytest`` plugins | ||
| that are used by Astropy, and will also be of general use to other packages. |
There was a problem hiding this comment.
I would say managed rather than used, but if the plan is used, then I suggest to add pytest-mpl to pytest-astropy, too as astropy uses it.
There was a problem hiding this comment.
Hmm, that's a good thought. Does @astrofrog think that pytest-mpl should be added to pytest-astropy as well? The main benefit would be a slight simplification to the CI scripts.
| Developers who want to run the test suite will need to install the testing | ||
| package using pip:: | ||
|
|
||
| > pip install pytest-astropy |
There was a problem hiding this comment.
do we plan to conda package them, or pip will always be the preferred way of installation?
There was a problem hiding this comment.
It seems like a good idea to eventually distribute this through conda. We can leave the documentation as-is for now and update later if appropriate.
There was a problem hiding this comment.
sure, this was more like a question than a review item to be addressed here.
| # Note, this is retained for backwards compatibility but the remote_data | ||
| # decorator is now provided by the pytest-remotedata plugin, and does not | ||
| # need to be imported from astropy. | ||
| from ...tests.helper import remote_data |
There was a problem hiding this comment.
I would totally remove this from the docs. We provide the backward compatibility, but the narrative docs should only contain the recommended way of usage.
bsipocz
left a comment
There was a problem hiding this comment.
Overall looks good, I only had a few inline comments.
|
|
||
| Below is an outline of the required changes: | ||
|
|
||
| * It is no longer necessary to import ``remote_data`` from ``astropy.tests.helper`` |
There was a problem hiding this comment.
This is confusing for affiliated packages. Write explicitly what one should do to ensure one can mark @remote_data and get no errors upon execution (from flake8 if nothing else)
There was a problem hiding this comment.
Thanks for the feedback. Hopefully this is clearer now.
There was a problem hiding this comment.
Yes, now it is very clear! Thanks.
623255a to
cfa198e
Compare
pllim
left a comment
There was a problem hiding this comment.
Currently, this seems the only place where the new standalone plugins' usage is documented. That is not ideal for people who want to use these new plugins but have no interest in astropy itself. Are there any plans to move the usage doc here out to the new packages? Then, we can simply link to those docs from here.
I'm a bit late to the code review part, but when I opened up the new display.py and config.py, I see complains about "unused imports" (are they imported but unused on purpose?).
Also see some individual comments below.
Thank you for all the hard work!
|
|
||
| Since the testing dependencies are not actually required to install or use | ||
| Astropy, they are not included in ``install_requires`` in ``setup.py``. | ||
| However, for technical reasons it is not currently possible to express these |
There was a problem hiding this comment.
Is there an issue or PR that explains this technical reason? If so, is it overkill if we link that here? This is because, "for technical reasons" is too vague if a future developer that is not Dan tries to address this.
There was a problem hiding this comment.
There is not currently an issue. Basically it's inherent in the design of the test runner, which is one motivation for getting rid of it if possible.
There was a problem hiding this comment.
This issue doesn't exactly explain the problem, but is relevant: #6787
| The plugin also adds the ``--remote-data`` option to the ``pytest`` command | ||
| (which is also made available through the Astropy test runner). | ||
|
|
||
| The default behavior is to skip tests that are marked with ``remote_data``. If |
There was a problem hiding this comment.
The second sentence seems to be repeating the first sentence but with more details. Is the first sentence even necessary?
|
|
||
| Providing either the ``--remote-data`` option, or ``--remote-data=any``, will | ||
| cause all tests marked with ``remote_data`` to be executed. Any tests that are | ||
| marked with ``internet_off`` will be skipped. |
There was a problem hiding this comment.
I never knew --remote-data skips internet_off -- Has this always been the case? I don't see why they have to be mutually exclusive. Just because I want one test to access internet doesn't mean I want to skip another test that does not need internet. But then again, I never used internet_off option myself...
There was a problem hiding this comment.
The internet_off decorator was introduced by the latest changes. However, I agree that the current implementation is not the most useful. There's an issue for this now: astropy/pytest-remotedata#17
| cause all tests marked with ``remote_data`` to be executed. Any tests that are | ||
| marked with ``internet_off`` will be skipped. | ||
|
|
||
| Running the tests with ``--remote-data=astropy`` will cause only tests that |
There was a problem hiding this comment.
Does this also skip internet_off like --remote-data=any?
There was a problem hiding this comment.
Yes, I'll add a comment here.
| pytest-doctestplus | ||
| ================== | ||
|
|
||
| The `pytest-doctestplus`_ plugin provides advanced doctest features, including: |
There was a problem hiding this comment.
Nitpick: Do we need to use double-backticks around doctest to render it as doctest since "doctest" is not a real word? I'll leave it to the linguist to decide.
There was a problem hiding this comment.
Hmm, personally I think it's common enough term in python circles to not need backticks 😄
| pytest-openfiles | ||
| ================ | ||
|
|
||
| The `pytest-openfiles`_ plugin allows for the detection of open IO resources at |
|
|
||
| The test suite can be run directly from the native ``pytest`` command. In this | ||
| case, it is important for developers to be aware that they must manually | ||
| rebuild any extensions by running ``setup.py build_ext`` before testing. |
There was a problem hiding this comment.
I think setup.py test automatically runs doctest as well (does it still?), but that won't be the case here, right? We need to document any behavior difference, if applicable.
There was a problem hiding this comment.
Yes, good point. It also supplies --doctest-rst by default.
| API, please see the :ref:`changelog`. | ||
|
|
||
|
|
||
| Renamed/removed functionality |
There was a problem hiding this comment.
Nitpick: Should "removed" be capitalized by grammatical rules?
There was a problem hiding this comment.
No, I think this is fine.
[edit]
It could really probably go either way, but I just copied it from the docs/whatsnew/2.0.rst
There was a problem hiding this comment.
If there is a precedent, then it is okay. :)
| pytest plugins | ||
| ************** | ||
|
|
||
| The following pytest plugins were previously provided as part of the Astropy |
There was a problem hiding this comment.
In the diff above, there are double-backticks around pytest to render it as pytest; Should we be consistent here?
| from ``astropy.tests.pytest_plugins`` will need to make updates, although | ||
| backwards compatibility will be maintained in the meantime. | ||
|
|
||
| Below is an outline of the required changes: |
There was a problem hiding this comment.
This list is very valuable and should be move up to the actual testing doc, rather than be buried in "what's new". Instead what's new here can link to the relevant testing doc section for this.
There was a problem hiding this comment.
I actually disagree with this: I think it's not particularly relevant to most readers of the testing documentation, but it is important for affiliated package developers who need to know what changed in this Astropy release. But I can be persuaded otherwise if everyone else feels strongly about it.
There was a problem hiding this comment.
In my past experience with config refactoring back in 0.4, I never looked in What's New because I already knew what was new. Instead, I went straight to astropy.config section for the transition doc. But let's wait a bit for inputs from others.
There was a problem hiding this comment.
I would suggest to keep it; for my own affiliated package, I can use any help I can get in finding what things change!
|
@pllim, to address your general comment about plugin documentation, I'm in the process of improving the READMEs for each for the new plugin packages. I don't think we'll be publishing those on readthedocs, but we already link to the github repos where the READMEs will be available. |
6690da6 to
17a381b
Compare
|
These are the remaining issues brought up in this PR but out of scope. Please open new issues for them as needed:
|
|
Now that the plugins will be backwards compatible with the 2.0.x branch (once #6918 is merged), I wonder whether we can backport this PR, too? |
This PR contains documentation updates that correspond to the changes that have been introduced with #6606. The changes have been submitted as a separate PR in order to make them easier to review, but they should be merged at the same time as #6606.