Remove remaining testing of iris-grib and grib in general.

[pp-mo]

We still have Iris test code which reference details of iris-grib or GribMessage, or even (in grib1 support), the old GribWrapper class.

Everything grib-related needs to be divided into classes:

• generic integration usage of grib load/save : can stay as long as tests only refer to cube contents
• iris-grib specific : move to iris-grib
  • of these, some old tests are probably obsolete + can just be ditched

This comment attempts to describe how this should work.

Here's a list :

• in iris.tests
  • test_grib_load_translations.py : --> iris-grib (N.B. actually GRIB1-specific, should also be renamed)
  • test_grib_save.py : maybe --> iris-grib, or maybe obsolete
  • test_grib_save_rules.py : maybe --> iris-grib, or maybe obsolete
• in iris.tests.integration
  • test_grib2.py : --> iris-grib
  • test_grib_load.py : --> iris-grib
    • note: testing is integrational, cube-properties only : nevertheless does not belong in Iris, ideally : Also, source files are in iris-test-data, which could also be tidied out ?
  • test_pickle : the section TestGribMessage : --> iris_grib ?
  • in iris.tests.integration.format_interop
    • test_name_grib.py : stays?
    • test_pp_grib.py : stays?

Ideally, all of this can be moved to iris-grib integration and unit tests, except:

• the iris.tests.integration.format_interop tests (they only test cubes)
• Iris should have simple integration tests to check that the iris-grib interfacing itself works.
  • probably just short tests for loading GRIB1 and GRIB2 files, and saving to GRIB2.

[pelson]

Iris should have simple integration tests to check that the iris-grib interfacing itself works.

This is a statement I'm not entirely confident in. I'd be interested in exploring other options (such as an iris-integration repo) that allows us to do some more significant integration testing (even than we do today) without having an impact on the pace of development. A nightly integration test certainly appeals...

[pp-mo]

other options ... to do some more significant integration testing ... without having an impact on the pace of development. A nightly integration test certainly appeals...

Absolutely agree.
I think we have reached a point where we need to revise the testing to get back to useful CI tests that "just work". It could be by dividing a "CI acceptance" test set from the "full" tests. Alternatively, we could maybe provision our own self-maintained CI server to replace Travis testing.

Splitting the tests would require us to choose what we do about a change that passes CI tests but later turns out to fail "full" tests.
A self-provided CI service would need sufficient resourcing, and must still work for all developers.

I'm going to make an issue of this ... #2865

[DPeterK]

There's a broken link to now-removed GRIB saver functionality referenced in https://scitools.org.uk/iris/docs/latest/userguide/saving_iris_cubes.html#controlling-the-save-process, which we should also remove.

[pp-mo]

This is now done !
See #3745