split hazard module

[emanuel-schmid]

Changes proposed in this PR:

• divide the Hazard class into 3 modules, base, io and plot.
• the hazard.base module had more than 2000 lines and has passed the limits of best practices code file size by far.
• with this PR the Hazard class is inheriting from two classes which are preoccupied with read/write and plotting methods respectively
• for the user of the class nothing has changed at all.

This PR fixes #

PR Author Checklist

• [ ] Read the Contribution Guide
• [x] Correct target branch selected (if unsure, select develop)
• [x] Descriptive pull request title added
• [x] Source branch up-to-date with target branch
• [ ] Documentation updated
• [ ] Tests updated
• [ ] Tests passing
• [ ] No new linter issues
• [x] Changelog updated

PR Reviewer Checklist

• [ ] Read the Contribution Guide
• [ ] CLIMADA Reviewer Checklist passed
• [ ] Tests passing
• [ ] No new linter issues

[chahank]

Excellent PR! This will make the code much cleaner.

Regarding the tests, should the test for IO and Plot be made integration tests only? And should the integration tests for hazard also be split up? And should we aim (not in this PR) to add test for the Plot parts in the future?

[emanuel-schmid]

Should the test for IO and Plot be made integration tests only? 🤷 Imho:

• plots ought to be tested in integration tests only. For two reasons.
  1. how to write a proper unit test for plots is an unsolved problem.
  2. they take too long.
• io on the other hand can partly stay in unit tests, as long as it's fast and goes along the line assert read(write(x) == x.

Should the integration tests for hazard be split up? No strong feelings. But, in general, I agree: the modularization of the integration tests could be better structured. Currently we have somehow a mix of distribution patterns: single tested method (test_multi_processing), single tested module (eg, test_nightlight), multiple tested modules together (test_engine), functional category (test_plot, test_multi_processing as meant to be?). Hence assigning a test to an existing test module is somewhat arbitrary.

Adding tests for the Plot parts? Yes! (remember: we always aim for coverage 100% 😁)

[emanuel-schmid]

testing policy discussion to be continued