Testing Line Decisions

[milobanks]

In the epiworld repository, there are a lot of tests that wouldn't make much sense in Python. The bindings are mostly just a one-to-one pass through of data to the C++ side. This sort of relates to #67 in that a balance between duplication and safety/clarity needs to be struck. I can think of a few different classifications for what tests we might want. Do you agree with the below (@gvegayon)?

General "just-in-case" Tests

A few tests to make sure the bindings are working correctly at a high level, i.e. running a few simulations. I don't think we have to do as many as in the C++ code-base, as most of the Python bindings are generated via a system of macros (meaning that if one wasn't working, they likely all wouldn't work).

Python Specific

Some logic is Python specific, such as the saver and where it chooses to save CSV files. This should obviously be checked.

[milobanks]

I should also add that this decision should be made for both epiworldR and epiworldPy. Currently, epiworldPy has more coverage than epiworldR, so this should be thought about before writing tests for either library.

[milobanks]

Decision: The classification outlined in the issue body is adequate (GVY).