more thorough Framework testing

[tomeichlersmith]

This is linked to #48 but it is not required. I could imagine a testing solution which clones something link framework-testbench into another directory and includes the current Framework as a symlink or copy.

I think more thorough testing would be helpful to make sure that any future features introduced do not also introduce a regression or bug in another area of Framework (most recently seen with #93 which was unintentionally introduced by #78 ). This testing of Framework would also aid in providing some examples of how to test downstream processors.

Tests

This is just off-the-top-of-my-head. Many of these tests should also be combined with other tests in the same running mode to make sure (for example) performance logging and writing a histogram file works as expected during the same run. I wrote many similar tests for the HDF5-based framework https://github.com/LDMX-Software/fire/tree/trunk/test which might be a helpful reference. Separating the C++-only tests from running a separate full module is helpful for granularity.

• Unit Tests
  • conditions system
  • storage control
  • drop keep rules
  • event add/get
  • config (able to run python and get parameters)
• Production Mode
  • a histogram file
  • performance logging
  • reco processor depending on earlier products
• Recon Mode
  • a histogram file
  • performance logging
  • processor that depends on products created during that run
  • processor requiring products within input file
  • one input file to one output file
  • multiple input files to one output file
  • multiple input files to multiple output files (does anyone use this?)
• Exceptions
  • Configuration
    • config DNE
    • python syntax or running error
    • type deduction issues
  • Running
    • cleanly handle, print, and close exceptions from all callbacks
    • missing event product