bpo-24412: Adds cleanUps for setUpClass and setUpModule. #9190
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
warsaw
requested changes
Sep 11, 2018
Lib/unittest/case.py
Outdated
| tearDownModule.""" | ||
| while _module_cleanups: | ||
| function, args, kwargs = _module_cleanups.pop() | ||
| function(*args, **kwargs) |
There was a problem hiding this comment.
What happens if an exception occurs in function? Currently that will prevent other module cleanups from being called. Without looking at what's done for other cleanup functions, I think it might be better to catch the exception and continue processing, but OTOH consistency in behavior with other cleanups is best.
There was a problem hiding this comment.
Yes you're right, this doesn't work quite right here. The normal tearDown() neatly handles the exceptions so that all the cleanups will be called. I'll look into doing that here an in the class tearDown as well. Thanks for catching this!
| @@ -390,6 +404,8 @@ class TestCase(object): | |||
|
|
|||
| _classSetupFailed = False | |||
|
|
|||
| _class_cleanups = [] | |||
There was a problem hiding this comment.
Minor nit (maybe!): In this case, the blank line between these two class attributes may not be needed.
Lib/unittest/case.py
Outdated
| @@ -445,6 +461,12 @@ def addCleanup(self, function, *args, **kwargs): | |||
| Cleanup items are called even if setUp fails (unlike tearDown).""" | |||
| self._cleanups.append((function, args, kwargs)) | |||
|
|
|||
| @classmethod | |||
| def addClassCleanup(cls, function, *args, **kwargs): | |||
| """Same as addCleanup, excet the cleanup items are called even if | |||
Lib/unittest/case.py
Outdated
| tearDownClass.""" | ||
| while cls._class_cleanups: | ||
| function, args, kwargs = cls._class_cleanups.pop() | ||
| function(*args, **kwargs) |
There was a problem hiding this comment.
Same question as above with exceptions in function.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
I have made the requested changes; please review again. Thanks for the feedback Barry! Hopefully I haven't missed any edge cases, I think I have covered the possible exception scenarios now. |
|
Thanks for making the requested changes! @warsaw: please review the changes made to this pull request. |
warsaw
reviewed
Sep 14, 2018
| except Exception as exc: | ||
| exceptions.append(exc) | ||
| if exceptions: | ||
| raise exceptions[0] |
There was a problem hiding this comment.
I totally get why you have to do it this way, although it would be nice if we had trio's MultiError in the stdlib. :) It's unfortunate that we have to throw away all the other exceptions, but I don't know where you can stash them. E.g. IIUC, instance cleanups stash the exceptions on self.errors, but there's no such place on modules (unless this code adds it, which, yuck :)). The other alternative is to create something like a simple MultiError, add the exceptions to that, and then raise the MultiError (maybe only if len(exceptions) > 1?).
It seems like a lot of extra complication for hopefully an, um, exceptional case, so maybe punt on that for now. IOW, I'm cool with this, unless you have any other ideas.
warsaw
reviewed
Sep 14, 2018
Lib/unittest/case.py
Outdated
| except Exception as exc: | ||
| exceptions.append(exc) | ||
| if exceptions: | ||
| raise exceptions[0] |
There was a problem hiding this comment.
In this case exceptions could be stashed on cls so they don't get lost.
warsaw
reviewed
Sep 14, 2018
Lib/unittest/suite.py
Outdated
| finally: | ||
| _call_if_exists(result, '_restoreStdout') | ||
|
|
||
| def _createClassOrModuleLevelException(self, result, exc, parent, name): | ||
| errorName = '{} ({})'.format(parent, name) |
There was a problem hiding this comment.
This is Python 3.8, so what do you think about using f{parent} ({name})?
There was a problem hiding this comment.
Definitely! I wasn't sure how important maintaining the current style in the code is, I didn't want to jump the gun and make it 3.8 only if normally we try to keep the code more backwards compatible. I will move it to the f-string style :)
warsaw
approved these changes
Sep 14, 2018
|
But,oops, Travis is failing ;) |
That appears to have been a transient error; I restarted the build and it succeeded. |
|
Thanks Tal! I plan to finish this up tonight, looking into if I can improve the exception handling. |
|
I'm looking forward to it! IMO we should definitely have this available in 3.8. |
Doc/library/unittest.rst
Outdated
| @@ -1448,6 +1448,66 @@ Test cases | |||
|
|
|||
| .. versionadded:: 3.1 | |||
|
|
|||
| .. method:: addClassCleanup(function, *args, **kwargs) | |||
Doc/library/unittest.rst
Outdated
| .. versionadded:: 3.8 | ||
|
|
||
|
|
||
| .. method:: doClassCleanups() |
Doc/library/unittest.rst
Outdated
|
|
||
| .. versionadded:: 3.8 | ||
|
|
||
| .. method:: addModuleCleanup(function, *args, **kwargs) |
There was a problem hiding this comment.
It is not a method of TestCase.
Doc/library/unittest.rst
Outdated
| .. versionadded:: 3.8 | ||
|
|
||
|
|
||
| .. method:: doModuleCleanups() |
There was a problem hiding this comment.
It is not a method of TestCase.
Lib/unittest/suite.py
Outdated
| finally: | ||
| _call_if_exists(result, '_restoreStdout') | ||
|
|
||
| def _createClassOrModuleLevelException(self, result, exc, parent, name): |
There was a problem hiding this comment.
Shouldn't names parent and name be swapped or changed to more meaning names? The third argument is the method name and the forth argument is the module or class name.
| @@ -0,0 +1,2 @@ | |||
| Add ``addModuleCleanup()`` and ``addClassCleanup()`` to unittest to support | |||
There was a problem hiding this comment.
It may be worth to add references: :meth:`~unittest.TestCase.addModuleCleanup()`, :func:`~unittest.addModuleCleanup()`, :meth:`~unittest.TestCase.setUpClass()`, :func:`~unittest.setUpModule()`.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://bugs.python.org/issue24412
This issue is rather old so it could benefit from a refreshed discussion.
I think having the cleanUps be available for all of the setUp types makes sense, it keeps code cleaner by reducing try-catches and keeps the API consistent across all the setUps.
https://bugs.python.org/issue24412