You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose that, by version 0.8.0, we use pytest as the test runner and wait for a full transition until later.
pytest is a testing framework that has a lot more features than the included unittest that we currently use. Things like parametrization of tests, more granularity with respect to restarting tests, plugins and fixtures [which we may not use]. The main reason that I've found is it's a lot easier to write tests using pytest.
The pytest documentation provides some good reasons for switching over, and they support much of the unittest framework that we already use. If you have pytest installed, you can just run pytest from the project directory and the tests will run. We do have an issue with the naming of one of our helper tests that we use for plotting testPlotAttrs
getting picked up as a test and pytest complaining.
A short term transition would be to instruct the CI to use pytest rather than python setup.py test. This would require no [major] changes to the core of the project. However, I think we would get a lot from a full transition to pytest in the future.
The text was updated successfully, but these errors were encountered:
ClosesCORE-GATECH-GROUP#325 in that all testing is done through pytest now. The user
can run pytest from the main project directory where examples,
serpentTools, and tests exists to run all thes tests. The content
of the test has not changed, and should eventually be ported over
to proper pytest, rather than using the unittest class-based approach.
pytest 5.1.2 has been added to requirements-test.txt and is used
in the test script scripts/travis/testScript.sh
I propose that, by version 0.8.0, we use
pytest
as the test runner and wait for a full transition until later.pytest
is a testing framework that has a lot more features than the includedunittest
that we currently use. Things like parametrization of tests, more granularity with respect to restarting tests, plugins and fixtures [which we may not use]. The main reason that I've found is it's a lot easier to write tests usingpytest
.The pytest documentation provides some good reasons for switching over, and they support much of the
unittest
framework that we already use. If you havepytest
installed, you can just runpytest
from the project directory and the tests will run. We do have an issue with the naming of one of our helper tests that we use for plottingtestPlotAttrs
serpent-tools/serpentTools/tests/utils.py
Lines 210 to 212 in 7ae29a3
getting picked up as a test and
pytest
complaining.A short term transition would be to instruct the CI to use pytest rather than
python setup.py test
. This would require no [major] changes to the core of the project. However, I think we would get a lot from a full transition topytest
in the future.The text was updated successfully, but these errors were encountered: