Address lack of unit tests

[cjosey]

This is a tracking issue to keep a list of needed unit testing capabilities that need to be added to the code. This code is growing at a rapid rate, and ensuring that updates do not break the code is essential. Currently, the code is tested by setting seed = 1, running a simulation, saving the result, and comparing it against an updated version of the program. This is unsustainable.

Obvious tests:

• [x] CRAM solver.
• [x] matexp parallel code.
• [ ] Each integrator method. Using a separate, non OpenMC operator such that an analytic solution is known would be ideal. This would prevent needing to keep fully in sync with OpenMC.
• [ ] XML generation.
• [x] Depletion chain / matrix formation.
• [x] Parallel depletion chain formation.

Except for the third one, all of these should be relatively trivial to implement.

[cjosey]

This is now currently in progress on the tests branch on my local repo. Plan is to use the built-in python unit tests with a mock-up neutronics solver standing in for OpenMC (dummy reaction rates, etc), so that tests do not rely on it.

The current concern is how to do unit tests on the openmc_wrapper.py block. Any unit tests would implicitly become integral tests of the OpenMC API, and would be very hard to maintain. Suggestions welcome.

[paulromano]

@cjosey Have you had a look at the unittest.mock library? It allows you to create mock objects with specified behavior, so it could help to replace calls to the OpenMC API in openmc_wrapper.py.