Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Approach to building test-cases #121

Open
Krzmbrzl opened this issue Jul 27, 2023 · 0 comments
Open

Approach to building test-cases #121

Krzmbrzl opened this issue Jul 27, 2023 · 0 comments

Comments

@Krzmbrzl
Copy link
Collaborator

Krzmbrzl commented Jul 27, 2023

What is the reason for the non-standard (at least to my experience) approach to compiling the test cases?

Normally, the tests are part of the ALL target such that simply issuing make will compile the test cases as well. Then a simple call to ctest causes the already compiled tests to be executed.
However, in SeQuant (and apparently a couple of projects it depends on) the tests are explicitly removed from the ALL target and are therefore not compiled with a simple make. Instead, the tests are compiled and built when running ctest (or make check).

This seems a bit odd to me, as normally, users have the BUILD_TESTING variable to control whether or not they want to compile the tests or not.

The current approach seems to have a couple of disadvantages:

  • If one of the tests fails to compile, it is much less transparent what went wrong. Finding the actual compile error can be a bit cumbersome
  • Not having the tests included in the ALL target can lead to issues where one is thinking that the tests have been re-compiled, but they haven't. Or the tests have been broken in a way that would give a compile error, but it is not noticed until the CI is run (which hopefully checks this kind of stuff?)
  • It's quite confusing for outside collaborators, which are familiar with the typical cmake worklflow
  • (I often start compiling, then do something else and when I come back, I expect all compiling to be done. If the program then starts compiling again, when I try to execute the tests, this is somewhat annoying)

So I wonder: what are the advantages that lead you to choose this approach over the "standard" one?

P.S.: I would volunteer for rewriting the relevant parts to adapt the "standard" workflow, if this would be okay by you.

@Krzmbrzl Krzmbrzl changed the title Approach to build tests Approach to building test-cases Aug 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant