Testing policy

[andreapasquale94]

@MicheleCeresoli I would like to start a discussion on how we can improve the testing of the packages in the JSMD ecosystem.
I believe that a robust testing framework is crucial for maintaining the quality and reliability of our code and I would like to take inspiration from the testing setup SciML ecosystem has.

As an example:

• https://github.com/SciML/SciMLBase.jl/blob/master/test/runtests.jl
• https://github.com/SciML/SciMLBase.jl/tree/master/.github/workflows

Here are a couple of hot points I’d like us to consider:

Splitting Tests by Functionality (Grouping)

One approach we could take is to split our tests based on the functionality they cover.
This would involve grouping related test cases, which could make it easier to understand what each test is doing and why it’s important.
It could also make our test suite more organized and easier to navigate as well as run much faster.

What are your thoughts on this? Do you think it would be beneficial?

Downstream Tests

Another point to consider is the use of downstream tests.
These are tests that verify the end-to-end functionality of our packages, ensuring that all components work together as expected.

Downstream tests can be more complex and time-consuming than unit tests, but they provide a valuable check on the overall health of our ecosystem. They can help us catch issues that might not be apparent when testing components in isolation.
A clear example of these tests could be the downstream testing of FrameTransformations in Tempo and Ephemeris.

Regression Tests

Another point to consider is regression tests.
These tests verify block functionalities of our package when compared to other state-of-the-art software.