-
Notifications
You must be signed in to change notification settings - Fork 33
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
Add a --pdb option to stestr run #14
Comments
So we added the - -no-discover option already which does the same thing and calls subunit.run directly. All we need to do here is add to the docs around pdb usage to tell people what to do. |
I actually don't know if --no-discover will actually work for using pdb. It still subprocesses out which might cause an issue with pdb. Someone will need to test it works correctly with --no-discover before we call it implemented and just document how to do it. |
I just tested it and it works:
In contrast:
|
-n or --no-discover works for me too for executing a single test case with traces set up:
|
Ok cool, then lets document this as the recommended way to run tests with pdb in the stestr man page and close the issue. |
@mtreinish commented on June 27, 2019 2:39 PM:
Just as a reminder, even with |
@aspiers when you get a second can you try running your pdb workflow with: #271 The code there isn't quite ready to merge yet (it's been a wish list feature I've been working on and off for some time in the background that I finally got running) but it launches things in parallel using |
After adding
|
This commit adds a new flag --pdb to stestr running a test id (in a similar fashion to --no-discover) for when pdb is going to be invoked from the tests. Pdb has trouble running in situations where another process is launched (which is pretty much all of stestr, including with --no-discover). This commit adds a --pdb flag so that you can launch the test runner without any additional processes being launched. This will run the tests in a process capture the subunit output to an buffer and after the tests finish executing will pass that to the load command so it can write it to the repository and generate subunit-trace or any other output format (per the set flags). The tradeoff here is that the output will not be real time from the test instead it will only be processed until after the test executes. One thing to note is that if you're using a fixture to capture stdout that will sometimes take the output from pdb so you will be in the debugger but get no output. If you plan to debug a test suite with a fixture make sure to disable that first. Fixes #14
Right now if you want to run with pdb stestr breaks that. The way to workaround this is to call subunit.run or testtools.run directly. We point this out in the stestr development docs:
http://stestr.readthedocs.io/en/latest/developer_guidelines.html#running-the-tests
However there is no reason we can't just fast path stestr to call the testr runner directly if we want to use pdb. We probably don't want to store results in the repository in that case.
For an example of this being done, we added this to os-testr: https://github.com/openstack/os-testr/blob/master/os_testr/ostestr.py#L197-L210 we probably could steal that logic and dump it into stestr.commands.run.
The text was updated successfully, but these errors were encountered: