-
Notifications
You must be signed in to change notification settings - Fork 0
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
Refactor process() testing & cleaning cube masking/filtering logic #58
Conversation
…y process() & tests.
Update test to use aiihca.paa1jan.subset data.
Refactor args to test fixture.
Add process() test with heaviside_uv/t masking.
Added branch protections to this repo so it'll restrict merging without a review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I'd be able to comment of the design as it's a bit above my level...but I do have some suggestions
Paths are deliberately fake to prevent filesystem access.
Fix test_process_no_heaviside_drop_cubes() to assert against function outputs.
…() outputs. Removed mock assertions coupled to implementation details.
Rework the pressure level code to simplify logic. Add/expand tests to ensure heaviside uv/t code branches are tested.
Testing shouldn't assert against the sman variable as it's an internal implementation detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes are looking good to me! The masking logic looks like its doing what it should be, and I think is also easier to read.
From what I can understand, the tests look good too.
I just had a couple of small suggested changes to do with function names and docstrings which I think can now be updated to reflect changes in what the functions are doing.
All tests passed on Gadi! |
Update docstrings to reflect modified functionality.
@blimlim I've made the changes, which definitely make the docs better. Do you want to go over the fixes quickly & resolve any the sub-discussions you're happy with? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a re-review of the changes and it looks good. Note: I'm not a python expert so I might have missed some stuff.
As it's an evolving project, omissions can be fixed :-). We're in a better position now with testing covering key code blocks. |
The freak show is merged, with 100+ comments... |
Resolves #50 (also related to #14).
This is a fairly complicated PR around testing & refactoring the central
process()
workflow function inum2netcdf/um2nc
.This work is intended to provide initial testing & cleanup of
process()
, providing a framework to ensure the workflow is consistent over future refactoring steps.For background:
um2nc
processes UM files, modifying variables & saving to NetCDF filesum2nc
driver is theprocess()
workflow function (it's also the main API entry point)process()
was initially 140 lines of processing logic & too difficult to unit testprocess()
to focus on the workflow logicprocess()
shrank, I identified tricky logic & inefficient data handling (see Clean & optimise masking logic/workflow #50 notes)Known Problems:
process()
tests require substantial setup & multiple uglynestedmock.patch()
calls. This is partly due to complexity inprocess()
, touching separate I/O libraries.mule
andiris
fields file objects are complexspec=
option, sincespec
only detects init time attributesprocess()
doesn't return success or failure data for the cubesFuture steps/direction/thoughts:
process()
is likely to gain cube modification functionality as it is extracted fromcubewrite()
process()
tests should be flexible to expand to cover the additional mod stepsprocess()
needs reordering to divide into 3 broad steps: input I/O, cube modification, output I/Oprocess()
tests could be split into smaller chunks. This ought to reduce setup dependencies, reducing test setup burden (e.g. lessmock.patch()
nesting)For the review, any opinions on the restructure, gaps & correctness checks are welcome! It would be good to reduce the complex setup.