StopIteration raised when parsing unittest output

[elharo]

Description

What steps will reproduce the problem?

ran unit tests; otherwise damned if I know; see stack trace

Traceback

  File "/opt/anaconda3/lib/python3.8/site-packages/spyder_unittest/backend/unittestrunner.py", line 41, in finished
    testresults = self.load_data(output)
  File "/opt/anaconda3/lib/python3.8/site-packages/spyder_unittest/backend/unittestrunner.py", line 83, in load_data
    test_index = next(
StopIteration

Versions

• Spyder version: 4.1.5
• Python version: 3.8.1
• Qt version: 5.12.10
• PyQt5 version: 5.12.3
• Operating System: Darwin 17.7.0

Dependencies

# Mandatory:
applaunchservices >=0.1.7      :  0.2.1 (OK)
atomicwrites >=1.2.0           :  1.4.0 (OK)
chardet >=2.0.0                :  3.0.4 (OK)
cloudpickle >=0.5.0            :  1.6.0 (OK)
diff_match_patch >=20181111    :  20200713 (OK)
intervaltree                   :  None (OK)
IPython >=4.0                  :  7.19.0 (OK)
jedi =0.17.1                   :  0.17.1 (OK)
nbconvert >=4.0                :  6.0.7 (OK)
numpydoc >=0.6.0               :  1.1.0 (OK)
parso =0.7.0                   :  0.7.0 (OK)
pexpect >=4.4.0                :  4.8.0 (OK)
pickleshare >=0.4              :  0.7.5 (OK)
psutil >=5.3                   :  5.7.2 (OK)
pygments >=2.0                 :  2.7.2 (OK)
pylint >=1.0                   :  2.6.0 (OK)
pyls >=0.34.0;<1.0.0           :  0.35.1 (OK)
qdarkstyle >=2.8               :  2.8.1 (OK)
qtawesome >=0.5.7              :  1.0.1 (OK)
qtconsole >=4.6.0              :  4.7.7 (OK)
qtpy >=1.5.0                   :  1.9.0 (OK)
rtree >=0.8.3                  :  0.9.4 (OK)
sphinx >=0.6.6                 :  3.2.1 (OK)
spyder_kernels >=1.9.4;<1.10.0 :  1.9.4 (OK)
watchdog                       :  None (OK)
zmq >=17                       :  19.0.2 (OK)

# Optional:
cython >=0.21                  :  0.29.21 (OK)
matplotlib >=2.0.0             :  3.3.2 (OK)
numpy >=1.7                    :  1.19.2 (OK)
pandas >=0.13.1                :  1.1.3 (OK)
scipy >=0.17.0                 :  1.5.2 (OK)
sympy >=0.7.3                  :  1.6.2 (OK)

# Spyder plugins:
spyder_unittest                :  0.4.1 (OK)

[jitseniesen]

Hi @elharo, thanks for your report. It looks like there is something in the unittest output when you are running the tests that it confusing Spyder. Would it be possible for you to find out which of your tests is causing problems? Failing that, can you send me the output if you run unittest by hand from the command line?

[elharo]

with some effort I reverted to a state where it occurs. here's the CLI output in that case:

~/60001/ps4$ python -m unittest tests
Loading word list from file...
('  ', 55901, 'words loaded.')
.Loading word list from file...
('  ', 55901, 'words loaded.')
E...
======================================================================
ERROR: test_get_valid_words (tests.MessageTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests.py", line 22, in test_get_valid_words
    self.assertTrue( len(message.get_valid_words()) > 10)
TypeError: object of type 'NoneType' has no len()

----------------------------------------------------------------------
Ran 5 tests in 0.043s

FAILED (errors=1)

[elharo]

The bug in my code that caused a test to fail was that message.get_valid_words() returned None instead of a list.

[elharo]

The code in question is not open source so I don't want to attach it here, but neither is it hugely confidential. If you send me your email I can forward you a zip of the project in question.

[jitseniesen]

I can reproduce the stack trace with the following simple test:

import sys
import unittest

class MyTest(unittest.TestCase):
    def test_fail(self): 
        print('text', file=sys.stderr)
        self.assertEqual(1+1, 3)

The messages to stderr get interspersed with the unittest output. If you can use stdout instead, that would probably fix the issue. Another workaround is to run your tests using pytest, which does run unittest tests so you don't need to change anything (but there may be incompatibilities). I think the proper solution is what issue #76 proposes, but I am afraid there are no immediate plans to do this.