Application tests¶

Applications tests are designed to test that the applications work properly. Here we check that the workflow ties together okay, produces correct physics, etc. The sorts of things anticipated to be done at application level are:

• Integration testing: check that we can work through a workflow okay - units tie together correctly and the code interfaces external libraries correctly
• Physics validation: simulation produces expected distributions and we reconstruct with appropriate residual distributions.
• Load testing: check that we can run big data files or for long periods without crashing

Usually application tests will check code executing at the level of applications in the bin directory. This is not enforced, but it's probably good practice to get in the habit of exercising these applications as part of the testing regime.

Making a test¶

Application tests are done in python. There is a directory tree tests/integration/ that contains the application tests. There is a script tests/application_tests.bash that runs nosetests. This walks down the tree looking for folders like test_<dir> and files like test_<dir1>/test_<name>.py. It executes them in the same way as for the unit tests (look at the examples, or look at the unittest documentation). Tests can be nested, just each branch of the directory tree has to have a suffix like test_<dir>.

Physics validation plots¶

There is a directory in tests/integration/plots that is intended to contain physics validation plots. If you do make some plots, for example plotting emittance change through the experiment or detector residuals, it would be great to put those plots in here. As the code base matures, I would like to publish these plots along with the code release, by way of "proving" that the code works. Can even add some comment/legend on what the plot is and what it should look like to make these plots standalone - but at least if a question comes up, we should be able to push a link with a few lines of explanation.

Running the tests¶

Tests can be run either as part of the full test suite

bash tests/run_tests.bash

or just the application tests

bash tests/application_tests.bash

or just a particular test

python tests/integration_tests/test_path/test_to/test_my/test_test/test_my_test.py

Note: this does almost the same thing, but the application_tests.bash calls a routine called `nosetests' with some command line arguments, which in turn imports each test script and runs unittests. If you try to use MAUS configuration stuff, it will attempt to parse the arguments sent to nosetests and fail. If you need to use MAUS configuration stuff, move the python store of command line arguments (sys.argv) to a temporary store and in the test setUp and then put them back in the test tearDown.