key4hep / key4hep/k4SimDelphes
How to organize tests and where to get and store input data
- Dominant language
- C++
- Stars
- 6
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
As mentioned in #5 we would like to have the different converters (ideally), or at least have the converter part under test. The former would also allow us to check that we actually do the setup in the different readers correctly. This issue should serve a sort of discussion thread, because there are quite a few moving parts involved.
All of the above mentioned options require that we have some input files that we can then use in the tests. For some of the readers I think this is not really a problem, because in this case these inputs basically just comprise a few text files (e.g. Pythia), but for others we would need some binary input files (e.g. STDHEP or ROOT). Since the scale of these tests will probably be rather limited, it might be feasible to also just add a few binary input files to the repository.
Another question is on how we want to organize these tests. As a starting point I would suggest to write a small test utility that takes an edm4hep input file and a delphes input file and then simply compares these event-by-event to see if all the things expected from delphes are actually present in the edm4hep output. We could then run all the converters and the corresponding delphes readers and use the outputs from those as inputs to this test utility.
In the interest of covering the most possible cases with the smallest possible set of different inputs, another questions is which inputs should we use and where to get them.
If there are simpler / easier solutions to have at least parts of the whole thing under test I am also very much open to ideas into that direction.
Contributor guide
Research direction
Start with the discussion in issue #5 and review how the converters and Delphes readers currently handle edm4hep, Delphes, Pythia, STDHEP, and ROOT inputs. The issue does not name files or existing tests; first agree on the test organization, fixtures, and comparison approach. Done means a decided, maintainable plan for inputs and converter coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100