-
Notifications
You must be signed in to change notification settings - Fork 25
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
Initial unit testing implementation #89
Conversation
I think this is a good start, we can get the physical tests in later. A minor point is that some of the new idealized cases (like the single_column and channel, maybe even fuk95) could be used for real science as well, not just for testing. So I wonder if |
It doesn't really matter what the The I think we maybe should add an additional |
I tried the test procedure on Betzy and it worked well! We have an ongoing discussion on the directory structure of the repository (#86), but it seems fairly straightforward to relocate things when that has been settled. One thing I would have preferred is that the output from tests is relative to the "builddir" given as argument to Meson. I typically locate the "builddir" outside of the repository and writes output on my scratch area. The updated .gitignores ensures that the test output does not interfere with git, but cleaning up after a test is a bit cumbersome since the "limits" file should be preserved in the test run folder. |
Change the 'workdir' variable (the folder where tests are run) to the current build directory. This necessitates a copy of the 'limits' configuration file as well.
I change the configuration around so that this is indeed the case. |
Thanks for making that change, @nordmoen! |
This PR contains the initial implementation for unit testing in BLOM. The PR introduces a new sub-directory,
tests
, which contains unit tests to run. Currently onlyfuk95
is complete and running. The README has been updated to reflect the unit testing setup.This PR also contains an updated CI configuration which will run both build and test for all targets and separates out OpenMP to catch problems earlier. In addition this PR skips MacOS builds with MPI as that has given some strange dependency issues. Tests are currently not run with MPI as that is not working locally either.
The next steps for unit testing would be to parse the output of the completed runs and compare the result with known good output, so that deviations from this can automatically be detected.