-
Notifications
You must be signed in to change notification settings - Fork 8
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
Moving tests outside package #143
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #143 +/- ##
=======================================
Coverage 71.53% 71.53%
=======================================
Files 152 152
Lines 20159 20159
Branches 3343 3343
=======================================
Hits 14420 14420
Misses 4906 4906
Partials 833 833 ☔ View full report in Codecov by Sentry. |
I disagree with this - if we remove these clauses then we have to run |
Will there be any path issues with the tests now effectively belonging to a package named |
LGTM otherwise 😄 |
You can also type
Yes, we will need to get rid of that too, at least over time, since those subclasses cannot use fixtures and parametrization decorators, see: https://docs.pytest.org/en/latest/how-to/unittest.html
I don't see any issues. A lot of packages do this: https://github.com/pydantic/pydantic/tree/main/tests, https://github.com/tiangolo/fastapi/tree/master/tests |
This PR moves the
tests
directory outside the package.In this PR:
--user
install in CI workflow (not sure if there was a good reason for it?).github/workflows/run_tests.py
- I think we don't need this file and we can put any pytest config items intoci.yaml
orpyproject.toml
.tests
directory outside package. This has some benefits, most importantly it's there is less of a danger of accidentally run the tests against the source files rather than the installed version. See also https://docs.pytest.org/en/7.1.x/explanation/goodpractices.htmltestssytems
->systems
andTestMolecule
->MoleculeTestSystem
, etc. This is to prevent accidental collection (I believe the exact rules should betest_*.py
filename andTest*
class name and no__init__
method, however I saw some issues around the collection and it's best not to cut too close to the rules and make it confusing.__init__.py
files, other thantests/__init__.py
. This one is still needed, since we import fromtests/systems.py
andtests/common.py
and have used"--import-mode=importlib"
(which is recommended, but makes imports across tests difficult). Ideally, I would like to move away from heavy cross-test importing and use a modern, fixture-based design. This will then reduce the issues around importing.if __name__ == '__main__'
clauses andunittest
imports. We have commited topytest
now, which is the de facto standard, let's not make it confusing by seemingly (but not really) support other modes of running the tests.