Be explicit about test coverage and add footnotes #190
Conversation
for more information, see https://pre-commit.ci
README.md
Outdated
| @@ -40,8 +40,8 @@ How does the package use scverse data structures (please describe in a few sente | |||
| - [ ] The code is publicly available under an [OSI-approved](https://opensource.org/licenses/alphabetical) license | |||
| - [ ] The package provides versioned releases | |||
| - [ ] The package can be installed from a standard registry (e.g. PyPI, conda-forge, bioconda) | |||
| - [ ] The package uses automated software tests and runs them via continuous integration (CI) | |||
| - [ ] The package provides API documentation via a website or README | |||
| - [ ] The package uses automated software tests that cover all public functions and runs them via continuous integration (CI)[^1] | |||
There was a problem hiding this comment.
It is the correct expectation but a rather strong one. I'm fine with it but wonder what other people think. Maybe a quick question for zulip?
There was a problem hiding this comment.
It is strong, but maybe it can be made less imposing by adding a paragraph about what a public API should be.
I think we should advise people to rather make their public API smaller than to compromise its testing or documentation.
In anndata, we recently documented the callback parameter signature of anndata.experimental.read_dispatched and in the process discovered what we had made implicitly public (if experimental).
To avoid a bunch of private things being made public, we made it all more correct and slimmer, which improved clarity here a lot.
|
Updated as discussed on zulip |
I tend to repeat myself in package reviews about
This PR modifies the checklist to add some definitions in footnotes and adds an explicit statement that all public functions should
be covered by tests. Is that asking too much?