Develop a coherent (automated) testing process #18
Description
I don't really believe in unit testing, esp. not retrofitting it to a medium sized package like this one with so many small stable functions that work in themselves (they would all pass unit tests). The problem with low-level tests is that this package tends to fail with unexpected combinations of parameters passed into TileUnit or WeaveUnit constructors, generating topological errors in GDAL/shapely. It's essentially impossible to generate a comprehensive suite of these.
However, this package badly needs a testing plan, preferably a high-level approach.
The core of this could be the notebooks in the examples folder. If they all run and don't fail, or modded versions of them as python scripts run, and don't fail, then changes to the code could be tested against those 'integrated' tests.
The all-the-tiles and test-weave-map notebooks would be a good place to start.