How does one write unit tests for verifying a setup.py itself is correct?
I’ve been looking for examples to study but I haven’t uncovered any so far. It’s hard to figure out what the right search terms might be. Pytest examples preferred as that’s the testing tool used in an upstream project but I’d happy with anything at this point.
to install it (in a clean venv, of course) works without error, and the unit tests for your package itself all pass when running on the installed copy (a src directory tox/nox, or other tools are helpful here) on the various platforms and Python versions you support.
There isn’t great offline validation currently for package metadata, though
twine check --strict dist/*
will cover a few very basics (environment consistency and your package readme’s syntax, respectively). It is hoped to improve the latter in the future (or other tools) to cover more metadata.
So, you should replace python setup.py check with twine check dist/* (or better, twine check --strict dist/*, especially in CI and python setup.py bdist_wheel with python setup.py bdist_wheel with python -m build, or better, python -bb -X dev -W error -m build.
I’m not quite sure why you’re doing this, but it does ensure that you don’t pick up the local copy when testing.
I’m also not quite sure what
is all about, but here is where you would run pytest ../path/to/tests (or whatever your test runner is) to unit and/or integration test the installed package.
yep the cd is about helping to make sure we don’t pick up stray files.
the # run script bits are place holders for what will be tests but are right now just “run and look at screen to see if seems ok”. exit should have been deactivate