Make unit tests for nanoAOD-tools (and then CI)

[arizzi]

we need unit tests, once available we can implement continuous integration in gitlab

[AndreasAlbert]

Let's revisit this issue. I think CI would be fantastic. Some considerations:

Environment
Easiest to use is probably github actions. IIUC, nanoaod-tools can run standalone already, so the only hurdle is to make ROOT avaialble. This could be achieved by using a precompiled binary like e.g. in hepdata_lib.

Testing procedure
Modules can do two things: calculating new quantities and filtering. Simple but useful checks that come to mind:

1. Check that the code runs without crashing.
2. Check that the expected output branches are present and have the right length (if this is possible to know)
3. Check that the output numbers are as expected by comparing to a "known-to-be-good" reference file.
4. Check for unintended consequences by testing whether branches that are meant to be unchanged are really unchanged.

Scope
Ideally, we'd have tests for everything, but that's not immediately realistic. A good start would be to have simple checks (1 above) for most things that are in regular use and implement stricter checks (2-4) for everything that can easily go wrong, or is just fundamentally important everywhere. Things that come to mind for the second category:

• JES / JER implementation for 2016+2017+2018 nanoaod v5 and v6.
• core framework functionalities: branch filtering, collection merging, etc.

Thoughts?

[arizzi]

please note we can also use gitlab like we do for cmssw tests of nanoaod and we have a VM at cern nanoaod.cern.ch (hosting the dqm for example) that in principle can be used to run scripts and crons .
Working without cmssw is not possible for many POG modules as we get the calibration interfaces from the releases.
In any case if someone can start writing unit tests than I guess we can help providing gitlab integration.

cheers,
andrea

[peruzzim]

definitely, @AndreasAlbert if you could put together a few tests it would be very useful, and we can easily integrate them with the validation routine we are already using for the development of the data format