Possible to structure tests so all tests in subpackages will run without import errors?
已回答
I have a package structure like this:
\myprogram
\myprogram\tests
\myprogram\integration_tests
\myprogram\subpackage
\myprogram\subpackage\tests
etc.
If I right-click on \myprogram\tests and choose "Run 'Unittests in tests'", they work. Great. But if I right-click on \myprogram and choose "Run 'Unittests in myprogram'", those same tests in \myprogram\tests now fail because they are no longer able to import files from their own package. eg. \myprogram\tests\test1.py can no longer import \myprogram\tests\test_helper.py.
A similar problem applies to \myprogram\subpackage\tests - if I choose that directory directly and run tests inside it, they work. If those tests are discovered by running from a parent directory, import errors happen.
This is both slightly inconvenient (as we not only have to run tests and integration_tests separately, but have to test each package and sub-package explicitly and individually) and ruins our coverage testing (because testing \myprogram will use code from subpackage, but won't have run the tests in subpackage\tests)
What can we do about this?
(Also, while I'm here, marking a folder as Excluded doesn't seem to exclude it from being found by 'Run Unit Tests In...' Bug, or feature?)
\myprogram
\myprogram\tests
\myprogram\integration_tests
\myprogram\subpackage
\myprogram\subpackage\tests
etc.
If I right-click on \myprogram\tests and choose "Run 'Unittests in tests'", they work. Great. But if I right-click on \myprogram and choose "Run 'Unittests in myprogram'", those same tests in \myprogram\tests now fail because they are no longer able to import files from their own package. eg. \myprogram\tests\test1.py can no longer import \myprogram\tests\test_helper.py.
A similar problem applies to \myprogram\subpackage\tests - if I choose that directory directly and run tests inside it, they work. If those tests are discovered by running from a parent directory, import errors happen.
This is both slightly inconvenient (as we not only have to run tests and integration_tests separately, but have to test each package and sub-package explicitly and individually) and ruins our coverage testing (because testing \myprogram will use code from subpackage, but won't have run the tests in subpackage\tests)
What can we do about this?
(Also, while I'm here, marking a folder as Excluded doesn't seem to exclude it from being found by 'Run Unit Tests In...' Bug, or feature?)
请先登录再写评论。
Hi. I split into individual files. For example a_tests.py, b_tests.py. I can configure the testing files by prefix because I use `pytest`
2017.x versions have completely new test runner support, so I believe the problem is obsolete now. There may be some confusing still, especially with unittest, the rule of thumb here: if one can't run tests from the terminal (with unittest discover) - it probably won't work in PyCharm neither.
If it's working in the terminal but not in PyCharm it may be a bug on our side - please feel free to create a ticket in our tracker / a new thread on the forum / or comment here and ping me. Thank you!
I think this conversation has lost track of what I was originally trying to say. Certainly the prefix issue is not relevant.
The problem was specifically the issue of being able to run the same test from different directories. Tests typically import modules from outside their own directory/package structure. Those imports are often quite sensitive to the current working directory. So a test that works in some conditions - e.g. running the whole directory - might not work when running the test directly, or when running all the tests a directory further up.
I'm not at my copy of Pycharm now so I'm unable to test how the newest version behaves. Certainly Python import weirdness is a feature of the language rather than Pycharm; but my interest is in how Pycharm attempts to facilitate quick unit testing, specifically with options like the "run unit tests in...<directory>" which automatically set up an executable context for those tests.
I've never made any claim about running tests in the terminal and that isn't relevant to me either.
I see, thank you for clarification Ben! If you can check the newest version it would be a very valuable feedback for us. I believe you're using relative imports in your tests, is it right?
Yes, I am using relative imports in many places - these are important to allow modularity.
It's hard for me to tell whether this is fixed or not because I'm hitting a new bug that never used to be there - the 'source roots' are not being added to the path, even though I have that enabled, so the tests can't import some of my modules any more. Perhaps this is a "feature" of the new test runner support?
I'm surprised we've left this gentleman without a clarification.
The issue is reproducible even in 2021 (4 years after).