[issue22680] unittest discovery is fragile

Robert Collins added the comment: 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. -- ___ Python tracker

[issue22680] unittest discovery is fragile

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22680] unittest discovery is fragile

Ethan Furman added the comment: 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

[issue22680] unittest discovery is fragile

Michael Foord added the comment: 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. -- ___ Python tracker

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: Or perhaps everything that has as a __module__ something which has the attribute __unittest = True? (the attribute is there for a reason, right?) -- ___ Python tracker __

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: 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 *"). -- ___ Python tracker

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: > 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 :-) -- ___ Python tracker

[issue22680] unittest discovery is fragile

Ezio Melotti added the comment: 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? -- ___ Python tracker __

[issue22680] unittest discovery is fragile

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue22680] unittest discovery is fragile

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: Ok, apparently it's because I have "from unittest import *" somewhere. -- ___ Python tracker ___ ___

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: testFunc contains "runTest" (!). -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue22680] unittest discovery is fragile

Michael Foord added the comment: 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.) -- ___

[issue22680] unittest discovery is fragile

Antoine Pitrou added the comment: > 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 compili

[issue22680] unittest discovery is fragile

Michael Foord added the comment: 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 han

[issue22680] unittest discovery is fragile

New submission from Antoine Pitrou: 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