Conversation
|
When this comes to merging, we'll need to redo the new test outputs, as #280 fixed a bug that affects the output. |
|
We will have to decide what to do regarding the testing regime. At the moment is, I think, overly complicated/redundant. I'd like it to be simpler and more systematic. In my mind this branch was supposed to be the starting point for a new set of tests to replace the current ones (sometimes it's easier to start over from scratch, then trying to fix something but maybe it is just me). Any thoughts? |
|
I think some of the existing tests should certainly be dropped, though it is probably worth having a overlap period where we introduce the new ones but keep the others in place for a while. Does that sound reasonable? We can use codecov to check that our new tests cover all the code lines that the old ones do before deprecating the old ones. I agree that several of the existing tests are overkill and overlap too much. |
|
We also need to manufacture a few minimal tests that trigger the numerical differences between Linux and Mac, to help diagnose the cause. If we can strip out as much as possible and still see the issue then that helps. |
|
Yes I agree. I think it's better to have more, but simpler/shorter tests, rather then the current system which runs complete models. |
|
Such a text file might be useful - not sure how to best implement that. In the meantime, can you tell me what the tests in this PR do? What are their analytic solutions? |
|
I was thinking something really simple as: I will email you about the tests in this PR. |
I started assembling some simple models that can be solved analytically. This is to address issues #47 and #265. At the moment the tests are not executed by travis or
make test.