Test dtype in time preproc #1240
Conversation
… test_dtype_in_time_preproc
Codecov Report
@@ Coverage Diff @@
## main #1240 +/- ##
==========================================
- Coverage 85.54% 85.53% -0.02%
==========================================
Files 188 188
Lines 9154 9158 +4
==========================================
+ Hits 7831 7833 +2
- Misses 1323 1325 +2
Continue to review full report at Codecov.
|
| # standardize the results if requested | ||
| if standardize: | ||
| cube_stddev = climate_statistics(cube, | ||
| operator='std_dev', |
There was a problem hiding this comment.
eugh! we really need to deactivate in-line comments from codecov, it makes review really annoying 😖
There was a problem hiding this comment.
son of a moose, if you just press "a" on the keyboard you can toggle the codecove comments 😁
| @@ -55,6 +51,12 @@ def _create_sample_cube(calendar='gregorian'): | |||
| return cube | |||
|
|
|||
|
|
|||
| def assert_equal_and_same_dtype(result, expected): | |||
| """"Check data is identical to the expected one.""" | |||
There was a problem hiding this comment.
all the _time functions apart from climate_statistics should not alter the dtype but if they do, there is no explicit check for that inside the respective function, so the test will fail with a very obscure assertion error, it's a good idea to plop a print statement here a la "Checking for dtype consistency between original cube data and preprocessor result" and then the developer will know what hit them
| tdim = cube.coord_dims('time')[0] | ||
| reps = cube.shape[tdim] / cube_stddev.shape[tdim] | ||
| if not reps % 1 == 0: | ||
| raise ValueError( |
There was a problem hiding this comment.
so I was trying to write a test for this statement here a la:
def test_standardized_anomalies_fail():
"""Test standardized ``anomalies`` failure due to shape mismatch."""
cube = make_map_data(number_years=0.01)
cube = cube[0:2]
print(cube.coord("time"))
with pytest.raises(ValueError):
anomalies(cube, period="season", standardize=True)which doesn't fail even if the cube's time axis is made up of two single points (two days) - surely this is something odd isn't it? Computing seasonal anomalies on two days should probably either fail or give the user a BIG warning data is totally unreliable?
This is a follow up from #1237.
It add checks for dtype conservation on time preprocessor tests
Closes #
Before you get started
Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.
To help with the number pull requests: