So, I tried to reproduce, but I actually see the same results with both of
these. However, they both show the issue I was hitting, namely, I got no
information on where the failure was located:
root@devstack-32:/opt/stack/neutron# tox -e py27 -v --
neutron.tests.unit.pcm.test_pcm
using tox.ini: /opt/stack/neutron/tox.ini
using tox-1.6.1 from /usr/local/lib/python2.7/dist-packages/tox/__init__.pyc
py27 reusing: /opt/stack/neutron/.tox/py27
/opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/python
/opt/stack/neutron/setup.py --name
py27 develop-inst-nodeps: /opt/stack/neutron
/opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/pip install -U -e
/opt/stack/neutron --no-deps >/opt/stack/neutron/.tox/py27/log/py27-163.log
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils
python setup.py testr --slowest --testr-args=neutron.tests.unit.pcm.test_pcm
/opt/stack/neutron$ /opt/stack/neutron/.tox/py27/bin/python -m
neutron.openstack.common.lockutils python setup.py testr --slowest
--testr-args=neutron.tests.unit.pcm.test_pcm
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpkYugPE
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpPoDsN3
ouch
======================================================================
FAIL: process-returncode
tags: worker-1
----------------------------------------------------------------------
Binary content:
traceback (test/plain; charset="utf8")
======================================================================
FAIL: process-returncode
tags: worker-0
----------------------------------------------------------------------
Binary content:
traceback (test/plain; charset="utf8")
Ran 4 (+4) tests in 0.348s
FAILED (id=150, failures=2 (+2))
error: testr failed (1)
ERROR: InvocationError: '/opt/stack/neutron/.tox/py27/bin/python -m
neutron.openstack.common.lockutils python setup.py testr --slowest
--testr-args=neutron.tests.unit.pcm.test_pcm'
______________________________________________________________________________________________
summary
_______________________________________________________________________________________________
ERROR: py27: commands failed
It looks like there was some traceback, but it doesn’t show it. Any ideas how
to get around this, as it makes it hard to troubleshoot these types of failures?
Here is the code:
# Copyright 2014 Cisco Systems, Inc. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
#
# @author: Paul Michali, Cisco Systems, Inc.
import sys
from neutron.tests import base
def using_sys_exit():
sys.exit(1)
def using_SystemExit():
raise SystemExit("ouch")
class TestSystemExit(base.BaseTestCase):
def test_using_sys_exit(self):
self.assertIsNone(using_sys_exit())
def test_using_SystemExit(self):
self.assertIsNone(using_SystemExit())
Regards,
PCM (Paul Michali)
MAIL …..…. [email protected]<mailto:[email protected]>
IRC ……..… pcm_ (irc.freenode.com<http://irc.freenode.com>)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
On May 1, 2014, at 1:23 PM, Yuriy Taraday
<[email protected]<mailto:[email protected]>> wrote:
On Thu, May 1, 2014 at 8:17 PM, Salvatore Orlando
<[email protected]<mailto:[email protected]>> wrote:
The patch you've been looking at just changes the way in which SystemExit is
used, it does not replace it with sys.exit.
In my experience sys.exit was causing unit test threads to interrupt abruptly,
whereas SystemExit was being caught by the test runner and handled.
According to https://docs.python.org/2.7/library/sys.html#sys.exit ,
sys.exit(n) is an equivalent for raise SystemExit(n), it can be confirmed in
the source code here:
http://hg.python.org/cpython/file/2.7/Python/sysmodule.c#l206
If there's any difference in behavior it seems to be the problem of test
runner. For example, it can mock sys.exit somehow.
I find therefore a bit strange that you're reporting what appears to be the
opposite behaviour.
Maybe if you could share the code you're working on we can have a look at it
and see what's going on.
I'd suggest finding out what's the difference in both of your cases.
Coming back to topic, I'd prefer using standard library call because it can be
mocked for testing.
--
Kind regards, Yuriy.
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
