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

Cleanup test suite #161

Merged
merged 74 commits into from
Oct 11, 2022
Merged

Cleanup test suite #161

merged 74 commits into from
Oct 11, 2022

Conversation

yardasol
Copy link
Contributor

@yardasol yardasol commented Jul 28, 2022

Summary of changes

This PR cleans up and overhauls the test suite to increase readability and future extensibility.

Specifically, this PR:

  • eliminates the saltproc.tests package and moves the tests directory to the base directory of the repo
  • moves pytest.ini to the base directory of the repo
  • adds a conftest.py file to tests/
  • Makes the following changes to the source files:
    • in app.py:
      • Eliminates global variables and adds parameters and return variables to functions previously missing them to facilitate proper unit testing
        • 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()
    • in depcode.py:
      • Remove materials.xml from default value for template_input_file_path
  • store depletion-code specific inputs data in new directories:
    • serpent_data
    • openmc_data
  • Changes to integration tests
    • 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.
    • (new) -> simple_reprocessing: reprocessing-related tests from test_app.py
    • (new) -> database_storage: database related tests from test-simulation.py
    • (new) -> file_interface_openmc: OpenMC file-related tests from test_depcode.py
    • (new) -> file_interface_serpent: Serpent file-related tests from test_depcode.py
  • Changes to specific unit tests:
    • test_app.py: Move testing of refill and reprocessing to an integration test, simple_reprocessing
    • test_depcode.py: Move testing of file writing to integration tests, file_interface_openmc and file_interface_serpent; split up into serpent and openmc tests.
    • test_ materialflow.py: Simplify file, syntax updates
    • test_process.py: Simplify file, syntax updates
    • test_separator.py: Simplify file, syntax updates
    • test_simulation.py: Move testing of database accuracy to an integration test, database_storage
    • test_sparger.py: Simplify file, syntax updates
  • updates references to changed function names in the docpages with their new names.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Required for Merging

  • I have read the CONTRIBUTING document.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
    • I have updated the documentation accordingly.
  • My change is a source code change
    • I have added/modified tests to cover my changes
    • I have explained why my change does not require new/modified tests
  • My change is a user-facing change
    • I have recorded my changes in the changelog for the upcoming release
  • My change is exclusively related to the repository (e.g. GitHub actions workflows, PR/issue templates, etc.)
    • I have verified or justified that my change will work as intended.
  • All new and existing tests passed.
    • CI tests pass
    • Local tests pass (including Serpent2 integration tests)

Associated Issues and PRs

Associated Developers

Checklist for Reviewers

Reviewers should use this link to get to the
Review Checklist before they begin their review.

@pep8speaks
Copy link
Contributor

pep8speaks commented Jul 28, 2022

Hello @yardasol! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2022-08-29 19:11:54 UTC

@yardasol yardasol mentioned this pull request Jul 28, 2022
16 tasks
@yardasol yardasol changed the title Cleanup tests suite Cleanup test suite Jul 28, 2022
@yardasol yardasol force-pushed the cleanup-tests branch 2 times, most recently from 56aabaa to c42be3c Compare July 28, 2022 23:51
@yardasol
Copy link
Contributor Author

@munkm bump

@yardasol yardasol requested a review from LukeSeifert September 8, 2022 18:54
Copy link
Member

@munkm munkm left a 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.


from the root directory of SaltProc.
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

doc/releasenotes/v0.5.0.rst Show resolved Hide resolved
pytest.ini Show resolved Hide resolved
@@ -102,7 +98,7 @@
"pattern": "^\\.\\/(.*)\\.xml$"}
},

"required": ["settings", "geometry", "materials", "chain_file"]
"required": ["settings", "materials", "chain_file"]
Copy link
Member

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?

Copy link
Contributor Author

@yardasol yardasol Sep 13, 2022

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.

Copy link
Member

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?

Copy link
Contributor Author

@yardasol yardasol Sep 27, 2022

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that makes sense!

tests/conftest.py Show resolved Hide resolved
tests/unit_tests/test_materialflow.py Show resolved Hide resolved
tests/integration_tests/run_constant_reprocessing/test.py Outdated Show resolved Hide resolved
np.testing.assert_allclose(test_param, ref_param, rtol=tol)


@pytest.mark.slow
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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

@yardasol
Copy link
Contributor Author

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.

Thanks!

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.

Which files are you talking about?

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.

I don't know. I've never used wheel.

@yardasol yardasol requested a review from munkm September 13, 2022 21:58
Copy link
Member

@munkm munkm left a 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.


from the root directory of SaltProc.
Copy link
Member

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?

doc/releasenotes/v0.5.0.rst Show resolved Hide resolved
pytest.ini Show resolved Hide resolved
tests/conftest.py Show resolved Hide resolved
tests/unit_tests/test_depcode_serpent.py Show resolved Hide resolved
@@ -102,7 +98,7 @@
"pattern": "^\\.\\/(.*)\\.xml$"}
},

"required": ["settings", "geometry", "materials", "chain_file"]
"required": ["settings", "materials", "chain_file"]
Copy link
Member

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?

@yardasol
Copy link
Contributor Author

Thanks for the review @munkm

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 somewhat agree with you, and somewhat don't. I think it's perfectly valid to prefix the input files with test_ because that elucidates their purpose (the intended purpose is that they are associated with tests). I'm not convinced that renaming the files to correspond to a specific design/configuration is particularly useful because we only have one such design/configuration right now for our unit tests. If down the road we are working with more than one configuration/design, then I think it makes sense to add more detail to those file names.

@yardasol yardasol requested a review from munkm October 4, 2022 16:31
@yardasol
Copy link
Contributor Author

@munkm if you don't have any further comments, can this be merged?

Comment on lines +21 to +22
#cp -r /usr/local/share/openmc openmc_src/share/.
#cp -r /usr/local/share/man openmc_src/share/.
Copy link
Member

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.

@munkm munkm merged commit 71b6e08 into arfc:master Oct 11, 2022
github-actions bot pushed a commit that referenced this pull request Oct 11, 2022
github-actions bot pushed a commit to khurrumsaleem/saltproc that referenced this pull request Oct 12, 2022
github-actions bot pushed a commit to yardasol/saltproc that referenced this pull request Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants