This adds an initial test suite using pytest, with some example tests, of how to write tests for code. This is a start to address some of the feedback from the ORR. The basic structure of a test suite is as follows:
All tests go under the tests folder
Tests are organized into sub-folders by module or package sub-directories
Tests for a given module / python file are named test_xxx.py. This makes them discoverable by pytest.
Individual tests for functions or methods within that module are named test_xxx. This makes them discoverable by pytest.
I.e. all tests for functions in the lvmdrp/utils/metadata.py module go within the tests/utils/test_metadata.py file. The goal or idea here is that every time you add a new function you should add a test for that function. When you change functionality you should also run the full test suite to make sure it didn't break anything else, or if needed, modify any tests that need updating.
I also added a new Github Action workflow for tests, that automatically runs the test suite on every commit and PR. This installs the DRP and runs the test for Python 3.8, 3.9, 3.10, and 3.11. See the Actions. Red means they failed for some reason. These will show up as successful or failed checks at the bottom of each PR. You want to make sure the checks pass before merging, or at least look at why things are failing.
The Github Action also performs a code linting check using ruff to ensure it is Pep8-compliant, but it is currently disabled since a large portion of the codebase fails and needs updating. Those changes can come in another PR.
To manually run the tests, from the top level directory, run pytest. This will run all the tests found in the tests directory and outputs success/failures, and a test coverage percentage of how well your code is covered by tests. Currently, we are at 6%. A good number to strive over is a test coverage of > 85%. The more tests we write, the more coverage we get. You will never get to 100% test coverage.
It also moves the setup.py options into a setup.cfg so we can easily update dependencies and add configuration for other things.
This adds an initial test suite using pytest, with some example tests, of how to write tests for code. This is a start to address some of the feedback from the ORR. The basic structure of a test suite is as follows:
testsfoldertest_xxx.py. This makes them discoverable bypytest.test_xxx. This makes them discoverable bypytest.I.e. all tests for functions in the
lvmdrp/utils/metadata.pymodule go within thetests/utils/test_metadata.pyfile. The goal or idea here is that every time you add a new function you should add a test for that function. When you change functionality you should also run the full test suite to make sure it didn't break anything else, or if needed, modify any tests that need updating.I also added a new Github Action workflow for tests, that automatically runs the test suite on every commit and PR. This installs the DRP and runs the test for Python 3.8, 3.9, 3.10, and 3.11. See the Actions. Red means they failed for some reason. These will show up as successful or failed checks at the bottom of each PR. You want to make sure the checks pass before merging, or at least look at why things are failing.
The Github Action also performs a code linting check using
ruffto ensure it is Pep8-compliant, but it is currently disabled since a large portion of the codebase fails and needs updating. Those changes can come in another PR.To manually run the tests, from the top level directory, run
pytest. This will run all the tests found in thetestsdirectory and outputs success/failures, and a test coverage percentage of how well your code is covered by tests. Currently, we are at 6%. A good number to strive over is a test coverage of > 85%. The more tests we write, the more coverage we get. You will never get to 100% test coverage.It also moves the
setup.pyoptions into asetup.cfgso we can easily update dependencies and add configuration for other things.This PR should be merged after https://github.com/sdss/lvmdrp/pull/41.