New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation of TestCase.runTest is incorrect and confusing #66349
Comments
The documentation for "unittest.TestCase" says "the standard implementation of the default 'methodName', runTest(), will run every method starting with 'test' as an individual test". However: >>> from unittest import *
>>> class Test(TestCase):
... def test_method(self): pass
...
>>> t = Test()
>>> t.run()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.4/unittest/case.py", line 552, in run
testMethod = getattr(self, self._testMethodName)
AttributeError: 'Test' object has no attribute 'runTest' After further experimentation, I see that if my test method is called "runTest", it can be automatically discovered, but only if there are no other test- prefixed methods. Perhaps you could drop the end of the second paragraph for TestCase, so that it just reads: Each instance of TestCase will run a single base method: the method named "methodName". I think the details about the test- prefix and counting results are covered elsewhere, and in most uses you wouldn't instantiate a TestCase yourself, so changing the method name is irrelevant. Also, perhaps under "TestLoader.loadTestsFromTestCase" it should say: If no methods with the usual name prefix are found, but the "runTest" method is implemented, there will be a single test case using that method. |
Updated documentation following suggestion. |
The patch seems reasonable to me |
IMO hiding the existence of |
Do you mean pretending there is no default “methodName” value, or pretending that the runTest() method is not invoked by discovery? I would have to check, but I think I have relied on the runTest() method being discovered in the past, when I did not think a more original test method name was useful. Though I agree that it makes the behaviour more complicated for little extra flexibility. |
runTest is part of the current API. I think if we're going to hide it we should do so as part of a deprecation path. (I'm +1 on hiding it). |
Le 28/10/2014 23:01, Robert Collins a écrit :
We don't need a deprecation path to remove something from the (and, while people may have chosen to use runTest, it doesn't mean they |
Removing stuff from the documentation would make it hard to understand what existing code means that uses runTest(). Isn’t this a case where you would add a big red “Deprecated since version . . .” warning instead? Maybe a comprimise would be to “hide” its documentation away in a separate deprecated section or something. |
Le 29/10/2014 00:22, Martin Panter a écrit :
Well, I wasn't proposing a deprecation (although that can be done as The simple way to hide it would be to stop documenting the TestCase |
Constructing test case objects directly is part of the protocol, and its needed for framework and extension authors. I've seen folk use runTest, but rarely enough that I think we could deprecate it. My argument is that while its supported we should be clear about when it should be used, and how. |
Oh, one thought - in testtools we split out 'docs for test writers' and 'docs for framework folk'. That would facilitate getting runTest out of test writers face while still documenting it appropriately. Related to that is my ongoing push to split the protocol so that these concerns are not intertwined the way they are today, but that needs to wait for the existing backlog to clear up :) |
I'll apply the patch monday if there are no further comments before then. |
This has already been discussed in the past, and IIRC there was consensus about giving unittest docs the same treatment. I don't remember if there was an issue for this. |
Updated patch with indentation fixed and new wording. I am just guessing the RST syntax based on the surrounding text, so please review :) |
Updated patch, which applies to current tip of the default branch, and includes the formatting fix. Also including a version that applies to the 3.4 branch. Alternatively, if you patch the 3.4 branch it looks like merging to default automatically gives the correct result. |
New changeset eefc157b3096 by Robert Collins in branch '3.4': New changeset 10f5a7fa26d5 by Robert Collins in branch '3.5': New changeset 45bd2dadbd0d by Robert Collins in branch 'default': |
Thanks for the update, it looks good to me. Applied to 3.4 and up. I'm not applying to 2.7 at this stage. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: