homepage

I just got the following traceback when trying discover without 3.5. It runs fine under 3.4...
$ ~/cpython/default/python -m unittest discover -v
Traceback (most recent call last):
 File "/home/antoine/cpython/default/Lib/runpy.py", line 170, in _run_module_as_main
 "__main__", mod_spec)
 File "/home/antoine/cpython/default/Lib/runpy.py", line 85, in _run_code
 exec(code, run_globals)
 File "/home/antoine/cpython/default/Lib/unittest/__main__.py", line 18, in <module>
 main(module=None)
 File "/home/antoine/cpython/default/Lib/unittest/main.py", line 93, in __init__
 self.runTests()
 File "/home/antoine/cpython/default/Lib/unittest/main.py", line 244, in runTests
 self.result = testRunner.run(self.test)
 File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 168, in run
 test(result)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
 return self.run(*args, **kwds)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
 test(result)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
 return self.run(*args, **kwds)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
 test(result)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
 return self.run(*args, **kwds)
 File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
 test(result)
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 625, in __call__
 return self.run(*args, **kwds)
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 553, in run
 result.startTest(self)
 File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 54, in startTest
 self.stream.write(self.getDescription(test))
 File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 47, in getDescription
 return '\n'.join((str(test), doc_first_line))
 File "/home/antoine/cpython/default/Lib/unittest/case.py", line 1354, in __str__
 self._testFunc.__name__)
AttributeError: 'str' object has no attribute '__name__'

I assume you mean you get the error *with* 3.5 (not "without"). Does this happen *every time* (i.e. is it trivially reproducible) - or can you provide a repro?
This is regression that I would *assume* (a totally lazy assumption) introduced by the new error handling code.

> I assume you mean you get the error *with* 3.5 (not "without").
Yes, sorry :-)
> Does this happen *every time* (i.e. is it trivially reproducible)
It happens with the llvmlite repository: https://github.com/numba/llvmlite
Since using it requires some compiling, I could try to investigate myself if you tell me what to look for.

As _testFunc is a string and shouldn't be, I'd be very interested to know *what* the string is. That may give us a clue as to where it has come from. (So a try...except...raise that also prints that value would be a good first step.)

testFunc contains "runTest" (!).

Ok, apparently it's because I have "from unittest import *" somewhere.

Does removing "from unittest import *" from somewhere fix the issue?
Is this a bug in your code, or did that import reveal a bug in unittest?

> Does removing "from unittest import *" from somewhere fix the issue?
Yes.
> Is this a bug in your code, or did that import reveal a bug in unittest?
Your choice :-)

btw, in case that's not clear from the traceback, discover was mistaking FunctionTestCase as one of my test classes (while it was just there because of the "import *").

Ah. Test discovery is discovering FunctionTestCase and attempting to instantiate it as a test. And failing.
Maybe discovery should special case that class and not treat it as a normal TestCase.

Or perhaps everything that has as a __module__ something which has the attribute __unittest = True?
(the attribute is there for a reason, right?)

Michael Foord opined:
---------------------
> Maybe discovery should special case that class and not treat it as a normal TestCase.
Not a bad idea. On the other hand, I don't believe unittest is advertised as supporting 'from ... import *', which *is* usually advised to be a bad idea.

This was reported as https://code.google.com/p/unittest-ext/issues/detail?id=71 a while back. I think blacklisting FunctionTestCase in TestLoader is entirely reasonable.

I agree.

Assuming that FunctionTestCase inherits from TestCase, a fix for Issue 14534 would be useful here. That bug is about avoiding TestCase subclasses being automatically run, which is useful for abstract base test classes.

I wrote a patch to blacklist FunctionTestCase in TestLoader, and a test to make sure FunctionTestCase doesn't show up in the TestSuite after loading a module that includes it. The test runs successfully. This is my first patch, so feedback would be appreciated if I did anything wrong.

Thanks for this. I think that a better approach would be the other linked bug - we can kill many birds with one stone.