Investigate property-based testing

[phargogh]

In working through #523, the subject of testing various valid ranges of possible properties (e.g. GDAL datatypes, numpy datatypes, presence/absence of nodata, etc.) that are used by various InVEST models. In testing the Stormwater model in #523, Emily followed the advice in the Pragmatic Programmer (2nd ed.) : "property-based testing". We ended up deciding not to pursue property-based testing in that PR, but it's worth taking a closer look at some point. Hypothesis looks like one possibility for enabling this kind of support in the unittest test fixtures.

Possible things to consider here are:

• Our test suite should continue to run as quickly as possible, so if we're running tests on combinations of properties, we should take a close look at the runtime.
• Once we've had a chance to prototype this, it'd be helpful to write up some guidance of what might make sense to test
• What happens when we have a test failure with a single property? Will we be able to easily reproduce the failure, and how?
• The premise of property-based testing sounds great, but how much of a burden will this be on us as we test? We'll want to be sure that the value property-based testing provides outweighs the developer cost.

[emlys]

Testing with signed byte rasters would be a good use for this. We don't normally use them in tests since they're a little more work to create programmatically. They probably should work, but it's hard to know without trying them out on every model.

[emlys]

Another use case: validation testing. Most models have a few test cases dedicated to asserting that different combinations of args do/don't return validation errors. Parameterized testing could help us run through those combinations more efficiently.

[emlys]

Another use case would be testing that all models can handle rasters with a nodata value of nan (#738)

[emlys]

758 : test all models with vector inputs in both GPKG and shapefile formats