You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bit of a late addition, but possibly there is some remaining value in the specific unit tests for GRIB1 loading here , which we will want to somehow replicate or preserve ?
However when we retire the old GribMessage and _grib1_load_rules, all this will also cease to function since it is based on creating GribMessage objects and calling grib1_convert.
For example, there is a mock-ist test designed to check that an unrecognised PDT produces a suitable error, and similar nearby tests to ensure that we can handle various recognised and unrecognised phenomenon codings.
At least, we should check the units tests of our new code, to ensure we have covered the same issues.
Likewise, there are some complex mechanisms here to check that various types of 'timeRangeIndicator' produce various types of bounded coordinate.
Quite apart from replicating the behaviour testing here, we need to be in a position to retire a lot of the aging unittest-based code which supports this, soon if not now.
The text was updated successfully, but these errors were encountered:
pp-mo
changed the title
transfer old grib1 loading unit tests to new GribMessage loader
replace old grib1 loading unit testing in new GribMessage-based loader
Dec 16, 2024
pp-mo
changed the title
replace old grib1 loading unit testing in new GribMessage-based loader
replace old GRIB1 loading unit tests in new-style loader
Dec 16, 2024
This is a bit of a late addition, but possibly there is some remaining value in the specific unit tests for GRIB1 loading
here , which we will want to somehow replicate or preserve ?
However when we retire the old
GribMessage
and_grib1_load_rules
, all this will also cease to function since it is based on creatingGribMessage
objects and callinggrib1_convert
.For example, there is a mock-ist test designed to check that an unrecognised PDT produces a suitable error, and similar nearby tests to ensure that we can handle various recognised and unrecognised phenomenon codings.
At least, we should check the units tests of our new code, to ensure we have covered the same issues.
Likewise, there are some complex mechanisms here to check that various types of 'timeRangeIndicator' produce various types of bounded coordinate.
Quite apart from replicating the behaviour testing here, we need to be in a position to retire a lot of the aging unittest-based code which supports this, soon if not now.
The text was updated successfully, but these errors were encountered: