-
Notifications
You must be signed in to change notification settings - Fork 16
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
Cleanup test suite #161
Cleanup test suite #161
Conversation
…code-specific directories; rename integration tests
56aabaa
to
c42be3c
Compare
@munkm bump |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think I'm done reviewing now! Thank you so much for these changes @yardasol !! I think there are lots of great improvements to the test suite here.
I am a little worried about calling the files used to and in the serpent/openmc runs test_
, as it sort of implies that's a file that's doing the test, not used by the test. Does that make sense? Maybe we could call them sample_
or something? I'm trying to come up with an alternative that would make them more differentiable from the actual test files.
Do you think there could be any issues by moving the tests folder out of the saltproc dir? I think this means it could be harder for a wheel build install to run the tests (which we don't use yet so it's not an issue) but I haven't double checked that so I could be wrong.
doc/installation.rst
Outdated
|
||
from the root directory of SaltProc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If one wants to run just the unit tests and not the integration tests, how would they do that here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can specify the path to the test(s) you want when calling pytest
. Alternatively, you can use the --ignore
flag followed by the path(s) to the test(s) you don't want to test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think that's worth explicitly stating here for people who may want to run unit tests locally when doing development. Can you please add it back in with the updated paths?
@@ -102,7 +98,7 @@ | |||
"pattern": "^\\.\\/(.*)\\.xml$"} | |||
}, | |||
|
|||
"required": ["settings", "geometry", "materials", "chain_file"] | |||
"required": ["settings", "materials", "chain_file"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so a geometry file isn't required any more? Won't that cause some issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A geometry file is required, but we have an entirely separate object for that, geo_files
, so we don't need to duplicate that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Ok, so I like the new geo_files object, but do you think it might be less intuitive that the geometry settings file path is not included in this input schema? All of the other paths are defined here. Would it potentially make it more difficult to read?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be confusing at first, but that's just how SaltProc is structured. We could try to change that in the future, but in the context of SaltProc's current structure, I think it would be more confusing for users to have two different geometry file specification parameters, because then which one are they supposed to use?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that makes sense!
np.testing.assert_allclose(test_param, ref_param, rtol=tol) | ||
|
||
|
||
@pytest.mark.slow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe say what this decorator is doing so future devs can use it appropriately if they add tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually not sure what it does. It was just in the previous version of the test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It tells pytest to run this "slow test" after all others. I.e. priority = last
Co-authored-by: Madicken Munk <madicken.munk@gmail.com>
Thanks!
Which files are you talking about?
I don't know. I've never used wheel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your responses @yardasol ! I tried to clarify some of my earlier questions since they weren't super obvious.
Which files are you talking about?
I'm talking about the .ini
and .json
files that start with test_
. Since they are specific designs and configurations, maybe we could name them with the functionality first, then say they're for tests. That way it doesn't seem like those files alone are test files. e.g. something like msr_input_test
.
I don't know. I've never used wheel.
I think that moving them here means they won't be distributed if we publish the package on pypi or conda-forge. That's ok (there are packages that choose to not do that, after all), but I think it's worth thinking about. Also, apparently the former convention seems to be a remnant from earlier rules around packaging . Anyways, we can always change it back if we encounter issues with this new structure.
doc/installation.rst
Outdated
|
||
from the root directory of SaltProc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think that's worth explicitly stating here for people who may want to run unit tests locally when doing development. Can you please add it back in with the updated paths?
@@ -102,7 +98,7 @@ | |||
"pattern": "^\\.\\/(.*)\\.xml$"} | |||
}, | |||
|
|||
"required": ["settings", "geometry", "materials", "chain_file"] | |||
"required": ["settings", "materials", "chain_file"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Ok, so I like the new geo_files object, but do you think it might be less intuitive that the geometry settings file path is not included in this input schema? All of the other paths are defined here. Would it potentially make it more difficult to read?
Thanks for the review @munkm
I somewhat agree with you, and somewhat don't. I think it's perfectly valid to prefix the input files with |
5eed7cc
to
8e2192b
Compare
@munkm if you don't have any further comments, can this be merged? |
#cp -r /usr/local/share/openmc openmc_src/share/. | ||
#cp -r /usr/local/share/man openmc_src/share/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can make a good first issue for somebody to remove these. I think if they're unused, we should just delete them and not comment them out.
…tests Cleanup test suite 71b6e08
…nup-tests Cleanup test suite 71b6e08
…nup-tests Cleanup test suite 71b6e08
Summary of changes
This PR cleans up and overhauls the test suite to increase readability and future extensibility.
Specifically, this PR:
saltproc.tests
package and moves thetests
directory to the base directory of the repopytest.ini
to the base directory of the repoconftest.py
file totests/
app.py
:read_main_input()
_print_simulation_input_info()
_create_depcode_object()
_create_simulation_object()
_create_reactor_object()
_process_main_input_reactor_params()
reprocess_materials()
get_paths()
refill_materials()
depcode.py
:materials.xml
from default value fortemplate_input_file_path
serpent_data
openmc_data
runsim_no_reproc
->run_no_reprocessing
: make datafile naming consistent, rely on a saltproc input file instead of module-level variables, internal variable name adjusments.cons_reproc
->run_constant_reprocessing
: make datafile naming consistent, internal variable name adjustments, use previously implemented but unused functions for testing reference results and test results.simple_reprocessing
: reprocessing-related tests fromtest_app.py
database_storage
: database related tests fromtest-simulation.py
file_interface_openmc
: OpenMC file-related tests fromtest_depcode.py
file_interface_serpent
: Serpent file-related tests fromtest_depcode.py
test_app.py
: Move testing ofrefill
andreprocessing
to an integration test,simple_reprocessing
test_depcode.py
: Move testing of file writing to integration tests,file_interface_openmc
andfile_interface_serpent
; split up into serpent and openmc tests.test_ materialflow.py
: Simplify file, syntax updatestest_process.py
: Simplify file, syntax updatestest_separator.py
: Simplify file, syntax updatestest_simulation.py
: Move testing of database accuracy to an integration test,database_storage
test_sparger.py
: Simplify file, syntax updatesTypes of changes
Required for Merging
Associated Issues and PRs
pytest.fixture
andpytest.raises
in the Test suite #155Associated Developers
Checklist for Reviewers
Reviewers should use this link to get to the
Review Checklist before they begin their review.