-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Make “good practices” match the future default import mode #8110
Comments
I have a similar situation that I'm not sure is addressed by the proposed recommendation. Consider the jaraco.abode project, which has a test suite at |
Currently importlib won't be the default due to these issues |
I wouldn’t frame this as issues, Ronny. It’s just behavior that differs from how people have done things. Behavior that enforces better practices, but isn’t widespread enough for better patterns to be widely used. Which is enough to be careful when changing things but isn’t an issue. @jaraco you just have to get those modules imported, either by getting them into PYTHONPATH or by manually importing them. E.g. by doing one of the following:
Think about how things are now: Many people basically define a separate global |
Thanks flying-sheep for the detailed response. Option 1 is a non starter. As I stated above, downstream packagers have specifically requested that tests not be included with the package. Over time, this has driven me from storing tests within the package to storing them in I'm a little unsure what option 2 is. Are you suggesting that Option 3 is dreadful. Not only does it require adding another boilerplate module to each project, but it requires a custom fixture for every possible functionality that needs to be available to the tests, specific to each test suite. This approach is far from sustainable, especially compared to the status quo (where a test suite can have importable, shared functionality).
That's understandable, but currently the only solution to #3396 (closed) is to use |
…rk with import-mode=importlib. Ref pytest-dev/pytest#8110.
…rk with import-mode=importlib. Ref pytest-dev/pytest#8110.
I tried this recommendation out in jaraco.abode, and sure enough, it seems to be mostly working. Two tests are failing due to some obscure edge case(s), but for the most part, moving The edge cases are rather obscure, and may be pointing to a misconception on my part about the approach. |
Well, you’d include test utils with the package. The actual tests aren‘t included. You’d have
Yes, |
Oh. When I added |
You replied at the same time as my above comment, please read what I wrote carefully. If you don’t want to use the import-via-path solution, you need to either install your test utils alongside the package before running the tests or add your test-utils-module’s containing directory to |
@flying-sheep those are issues as they break existing testsuites and depending in the setup it imposes hours of work and introducing own custom cargo culted sys.path hacks to hopefully get testing working, while still breaking a number of ways one would generally expect to import code as long as relative imports between test modules and relatively located test helper modules are not working its not something that can be used as a default as it just wrecks loads of things |
If you use Nothing breaks unless you deliberately migrate to a different import mode for an existing project. And each migration is effort if you choose to do it, yes. |
@jaraco you misinterpreted my suggestion when doing jaraco/jaraco.abode@446a488
|
I think I understand now - with There was a time when the prepend import mode did not support importable behavior not in the package. Because of this, I developed a habit of always including the tests in the main distribution package (installed), so they were importable and able to be modularized. Later, pytest started supporting importable behavior from test packages, making it possible to have a test suite with shared modules not installed as part of the package. Later, users started requesting that I move this behavior out of the package so that it's not installed (now considered a best practice). I'd like not to have to return to that prior expectation unless pytest is willing to defend that position (that all importable behavior must be installed). |
Fixed by #10206 |
The import mode docs say that the importlib mode will be the future default, and test modules will be unable to import each other.
That’s great, and promotes a distinction between
my_package.test_utils
andtest_*.py
test collections!I think in the good practices docs, this should be outlined more clearly, and the drawbacks of the
prepend
import mode should be deemphasized while promoting theimportlib
mode.Good practices should include not adding
__init__.py
to test directories:__init__.py
is just a workaround for theprepend
import mode, which should be phased out.The text was updated successfully, but these errors were encountered: