[openstack-dev] [Quantum]Debug unit test using pdb

Clark Boylan clark.boylan at gmail.com
Sat Jun 8 04:24:31 UTC 2013


On Fri, Jun 7, 2013 at 6:08 PM, Henry Gessau <gessau at cisco.com> wrote:
> tox creates a virtualenv in .tox/py27 which you should activate for
> debugging. Then use nosetests for running the test(s) in the debugger. Note,
> with nosetests you must use a colon when splitting from the module to the
> class level.
>
>   $ source .tox/py27/bin/activate
>   (py27)$ python -m pdb .tox/py27/bin/nosetests
> quantum.tests.unit.test_debug_commands:TestDebugCommands
>
> For some set_trace() tips, see
> http://stackoverflow.com/questions/4950637/setting-breakpoints-with-nosetests-pdb-option
>
> -- Henry
>
> On Fri, Jun 07, at 7:32 pm, Jason Zhang <bearovercloud at gmail.com> wrote:
>> Hi,
>>
>> I'd like to debug the quantum unit test case using the pdb, but it looks
>> like I got the errors regarding the
>> stdin/stdout for i/o of pdb when I run the command as followings,
>>
>> tox -e py27 -- quantum.tests.unit.test_debug_commands.TestDebugCommandsShell
>>
>> Traceback (most recent call last):
>>   File "/opt/stack/quantum/quantum/tests/unit/test_debug_commands.py", line 417, in test_initialize_app_help_return
>>     sh.run(argv)
>>   File "/opt/stack/quantum/quantum/tests/unit/test_debug_commands.py", line 417, in test_initialize_app_help_return
>>     sh.run(argv)
>>   File "/usr/lib/python2.7/bdb.py", line 48, in trace_dispatch
>>     return self.dispatch_line(frame)
>>   File "/usr/lib/python2.7/bdb.py", line 67, in dispatch_line
>>     if self.quitting: raise BdbQuit
>> BdbQuit
>>
Tox runs the unittests with testr which runs tests in parallel. This
makes dealing with stdout/stderr a little tricky. The current easy way
to use pdb without needing to manually source virtualenv's and run
nose is to do `./run_tests.sh -d` (you can also provide the specific
test here). This runs the tests with testtools.run which does not run
tests in parallel so we don't have to do funny things with
stdout/stderr. That said sourcing the virtualenv and running things
directly can be valuable as it much more flexible.

Clark



More information about the OpenStack-dev mailing list