WIP: Test framework

[tomasaschan]

I've started working on a small test framework for the ODE solvers. It uses FactCheck for verification, but I've made some modifications there as well, as well as used some code that is likely to move soon (JuliaLang/julia#2422), so this really isn't ready for merging yet.

But I very much like to hear what you think about the test API and the general look of the code so far =)

[vtjnash]

I think this seems right.

One thought, from my experience writing the basic tests, I think you will want the tolerances to be based on some combination of the difficulty of the problem and the accuracy of the solver. For example, the expectations of an ode23 solver are going to be lower than an ode45.

[tomasaschan]

True. Maybe we want yet another abstraction, which basically holds a problem, a solver and a pair of tolerance values. The test suite will the correspond to a list of (solver,problem,rtol,atol) tuples, which we iterate over and verify. This is probably needed anyway, since we need to keep track of different problem sets for different solvers, so we don't test non-stiff solvers on stiff problems etc.

On a related, but slightly tangential note, we also need to harmonize the API for the solvers. I haven't spent a lot of time looking at it, so it might not be that much to do, but I think the general form tout, yout = odeXX(f, tspan, y0) should go for all solvers for explicit problems, and that it should work with both scalar and vector y0. Possibly, yout should also mimic the dimensions of y0, so that a scalar y0 yields a vector (as opposed to matrix) yout. This is probably a separate issue, though...

[tomasaschan]

I'm closing this for cleanup, since the main ideas from here are already in our test suite...