Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider an iris.testing module #6210

Open
trexfeathers opened this issue Oct 31, 2024 · 3 comments
Open

Consider an iris.testing module #6210

trexfeathers opened this issue Oct 31, 2024 · 3 comments

Comments

@trexfeathers
Copy link
Contributor

📰 Custom Issue

Analogous to numpy.testing - a module where we can share our testing conveniences publicly.

We are in the process of implementing iris.tests._shared_utils. Here it is on its feature branch:

"""Provides testing capabilities and customisations specific to Iris."""

iris.tests._shared_utils contains the conveniences that originally belonged to the iris.tests.IrisTest class, which is going to be deprecated once we complete our move to PyTest. I think ideally this could become the iris.testing module.

Motivating factors

  1. The documentation we are writing in Added a style guide for iris pytest #5785 makes many references to this module, which of course isn't documented since it's within iris.tests and is private. It would be more helpful if in a public module, which would mean the references have something to link to.

  2. We know that we have users who use the conveniences in IrisTest / _shared_utils and find them very valuable. This is currently a rather loose contract since they are in private areas of the codebase. I think it would be good to make the conveniences explicitly open to use, although that may only be appropriate once we have finished the PyTest migration and learned all our lessons. If we're not comfortable with fully maintaining stable API we could perhaps incorporate some sort of warning that the code is subject to change?

@bjlittle
Copy link
Member

The only major downside of this is that we'd then need to "officially" support it.

Without getting all meta, are you proposing that we also test out testing infrastructure?

@trexfeathers
Copy link
Contributor Author

The only major downside of this is that we'd then need to "officially" support it.

Without getting all meta, are you proposing that we also test out testing infrastructure?

Agreed, it's not a slam dunk by any means.

And yes we would need to test things like assert_CDL if we went for this.

@rcomer
Copy link
Member

rcomer commented Nov 1, 2024

For (1), it is possible to document private modules
https://matplotlib.org/stable/api/_api_api.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants