These tests will actually cover the objects that make RScore (e.g. Individual, Landscape etc.) and would be beneficial for all interfaces, so it feels inappropriate to tie them to the batch interface.
As a solution, I'm considering adding a main() function to RScore, which sole purpose would be to call the run_tests() function currently living in the main of the batch version.
An added benefit would be that such a main would allow one to run RScore on GitHub Action, thus enabling continuous integration for the core code.
This main would however need to be excluded when compiling RScore with one of the interfaces. This is easy to do with CMake for the batch version, but maybe not so much for RangeShiftR. I'll seek a solution that does not break existing builds.
TheoPannetier
commented
8 months ago
I have started writing unit tests that are run in the main of the batch version:
https://github.com/RangeShifter/RangeShifter_batch_dev/blob/68ef4eba024207d173ff366a2ee0a6d66157a35d/src/Main.cpp#L100C24-L100C24
These tests will actually cover the objects that make RScore (e.g. Individual, Landscape etc.) and would be beneficial for all interfaces, so it feels inappropriate to tie them to the batch interface.
As a solution, I'm considering adding a
main()function to RScore, which sole purpose would be to call therun_tests()function currently living in the main of the batch version. An added benefit would be that such a main would allow one to run RScore on GitHub Action, thus enabling continuous integration for the core code.This main would however need to be excluded when compiling RScore with one of the interfaces. This is easy to do with CMake for the batch version, but maybe not so much for RangeShiftR. I'll seek a solution that does not break existing builds.