Running 1 test with --no-discover results in an error #244
Assignees
Labels
Comments
|
Thanks for filing this, I can confirm this is an issue, I actually hit it yesterday for the first time myself locally and was going to spend some time investigating it today. |
|
@relaxdiego So I've been doing some local debugging on my issues. There are 2 things going on, first the But it doesn't fix the underlying fault causing the lack of results. In my case in the local test suite where I was hitting this issue it was caused by a bug in testtools (well really unittest2) when running that test suite without discovery. It did raise an error from the subunit worker process when it tried to run the test specified and that's why there weren't any results. I'm thinking there might be an underlying error happening early in the test execution that's causing this for you too. Is the test suite you're running this on open so I can take a look? If not can you see if there are any other errors above the traceback you pasted here already? |
|
@mtreinish Thanks for the quick feedback! Below is the entire stacktrace. HTH! |
mtreinish
added a commit
that referenced
this issue
Jul 18, 2019
This commit fixes an edge case with the load command when there are no test events in the subunit stream being passed to load. If the pretty_out flag is set for the load command and there is no subunit output the processing being used to handle the test run timing will fail because there are no tests. This fixes that by just returning the test run failed (because there were no sucessful tests run). Fixes #244
|
I just pushed #255 which will fix the stestr issue reported here (which is the |
mtreinish
added a commit
that referenced
this issue
Jul 21, 2019
Right now stestr doesn't actually own it's own test runner. It leverages the subunit.run test runner, subunit.run in turn inherets from testtools.run, which inherets from unittest2. The usage of unittest2 causes all sorts of problems when running non-testtools or non-unittest2 test suites, because of mismatches between stdlib unittest and unittest2. To address this proble this commit creates a new test runner for stestr that will emit subunit which is the actual only hard requirement for the internal test runner used. This new test runner is more or less identical to subunit.run, but instead of inheriting from testtools it uses stdlib unittest directly. Python 2.7's stdlib unittest's test runner is much older and it was changed significantly for python 3. So building a custom test runner based on python 2's unittest would basically requiring maintaining a completely separate copy of python 3's unittest runner in tree and then building the subunit runner off of that, which is essentially what unittest2 is anyway. Since python 2 support is deprecated anyway and will be going away soon this commit just maintains the current status quo of basing it off testtools for python 2. Fixes #244 for the first stacktrace outlined there, which was caused by the test runner (which was previously outside the scope of stestr).
mtreinish
added a commit
that referenced
this issue
Jul 21, 2019
Right now stestr doesn't actually own it's own test runner. It leverages the subunit.run test runner, subunit.run in turn inherets from testtools.run, which inherets from unittest2. The usage of unittest2 causes all sorts of problems when running non-testtools or non-unittest2 test suites, because of mismatches between stdlib unittest and unittest2. To address this problem this commit creates a new test runner for stestr that will emit subunit which is the actual only hard requirement for the internal test runner used. This new test runner is more or less identical to subunit.run, but instead of inheriting from testtools it uses stdlib unittest directly. Python 2.7's stdlib unittest's test runner is much older and it was changed significantly for python 3. So building a custom test runner based on python 2's unittest would basically requiring maintaining a completely separate copy of python 3's unittest runner in tree and then building the subunit runner off of that, which is essentially what unittest2 is anyway. Since python 2 support is deprecated anyway and will be going away soon this commit just maintains the current status quo of basing it off testtools for python 2. Most of the code here for the Runner class and the TestProgram class were originally taken from subunit and testtools respectively. Fixes #244 for the first stacktrace outlined there, which was caused by the test runner (which was previously outside the scope of stestr).
mtreinish
added a commit
that referenced
this issue
Jul 21, 2019
Right now stestr doesn't actually own it's own test runner. It leverages the subunit.run test runner, subunit.run in turn inherets from testtools.run, which inherets from unittest2. The usage of unittest2 causes all sorts of problems when running non-testtools or non-unittest2 test suites, because of mismatches between stdlib unittest and unittest2. To address this problem this commit creates a new test runner for stestr that will emit subunit which is the actual only hard requirement for the internal test runner used. This new test runner is more or less identical to subunit.run, but instead of inheriting from testtools it uses stdlib unittest directly. Python 2.7's stdlib unittest's test runner is much older and it was changed significantly for python 3. So building a custom test runner based on python 2's unittest would basically requiring maintaining a completely separate copy of python 3's unittest runner in tree and then building the subunit runner off of that, which is essentially what unittest2 is anyway. Since python 2 support is deprecated anyway and will be going away soon this commit just maintains the current status quo of basing it off testtools for python 2. Most of the code here for the Runner class and the TestProgram class were originally taken from subunit and testtools respectively. Fixes #244 for the first stacktrace outlined there, which was caused by the test runner (which was previously outside the scope of stestr).
|
#256 will fix the issue outside of stestr currently. To address the first stack trace which was coming from unittest2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description
When attempting to run a single test method in test file, as specified in the documentation, stestr errors out with the following:
Expected behavior and actual behavior
It executes successfully with the following output:
Steps to reproduce the problem
Run a single test as per documentation:
Reference: https://stestr.readthedocs.io/en/latest/MANUAL.html#running-tests
Specifications like the version of the project, operating system, or hardware
System information
stestr version (
stestr --version): 2.3.1Python release (
python --version): Python 3.6pip packages (
pip freeze): attrs==19.1.0,charmhelpers==0.19.13,charms.openstack==0.0.1.dev1,charms.reactive==1.2.1,cliff==2.14.1,cmd2==0.9.12,colorama==0.4.1,coverage==4.5.3,entrypoints==0.3,extras==1.0.0,fixtures==3.0.0,flake8==3.7.7,future==0.17.1,Jinja2==2.10.1,linecache2==1.0.0,MarkupSafe==1.1.1,mccabe==0.6.1,mock==3.0.5,netaddr==0.7.19,os-testr==1.0.0,pbr==5.2.1,pkg-resources==0.0.0,prettytable==0.7.2,pyaml==19.4.1,pycodestyle==2.5.0,pyflakes==2.1.1,pyparsing==2.4.0,pyperclip==1.7.0,python-mimeparse==1.6.0,python-subunit==1.3.0,PyYAML==5.1.1,six==1.12.0,stestr==2.3.1,stevedore==1.30.1,Tempita==0.5.2,testtools==2.3.0,traceback2==1.4.0,unittest2==1.1.0,voluptuous==0.11.5,wcwidth==0.1.7Additional information
Running an alternative command as a workaround:
However, the above is slow since stestr first needs to discover all tests before it filters it down to the one I wanted to run.
The text was updated successfully, but these errors were encountered: