-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Split up tests? #5409
Comments
that sounds like a good idea, and we'll definitely have to do this gradually because PRs with several thousand lines of changes are really difficult to review. Probably unrelated, but I'd also like to refactor / reorder the tests in |
Yes, splitting up these giant test files would definitely be a good idea. I don't think there was ever a good reason why they needed be in a single class. |
Great, it seems there's some backing for this. What's the best way to start? I'm happy to do a PR to pull all the |
This is kind of a general question whenever we add new features: if I add to the API such that I can access my new computation |
Currently a large share of our tests are in
test_dataset.py
andtest_dataarray.py
— each of which are around 7k lines.There's a case for splitting these up:
test_variable.py
in some cases) — i.e. we're running the same test over a Dataset & DataArray, but putting them far away from each other in separate files. Should we instead have them split by "function"; e.g.test_rolling.py
for all rolling tests?If we do this, we could start on the margin — new tests around some specific functionality — e.g. join / rolling / reindex / stack (just a few from browsing through) — could go into a new respective
test_{}.py
file. Rather than some big copy and paste commit.The text was updated successfully, but these errors were encountered: