[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: Closing. The patch as suggested should not be applied. Instead tearDown should be called in a finally block in the setUp for this specific use case. I've created a new issue (#5679) for the cleanUp idea which I think is good. -- ___

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: OK, so the patch as submitted *isn't* for the cleanUp suggestion (d'oh - I should have read it before posting the last comment). One possibility is that this bug is closed as won't fix (the patch as provided should definitely not be applied as it is a big change

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Michael Foord added the comment: +1 on adding a cleanUp list where entries are executed unconditionally even on failure of setUp. If there is consensus that this is a good thing (looks like it to me from the discussion here) then I can apply the patch to head. I'll review it first and post any

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: As an FYI, I'm going to push this off until next week or the week after because I have more pressing things to take care of and have an OK workaround for this issue. -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: Unfortunately we're still stuck on 2.4.5 because I don't have enough buy-in from tech leads and architects to upgrade right now -_-... Good idea though :] *stores for later*. -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Kumar McMillan added the comment: For the record, I too have been plagued by failing setUp's :( and the pattern you describe is not uncommon. I was just pointing out that changing the semantics of tearDown() will affect a lot of existing code. As with any backwards incompatible change the effo

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: Excellent point Kumar. Here's what I'm trying to accomplish... I'm a part of a team that's testing out IOSd on an up and coming Unix foundation platform. This requires starting up a series of services, ensuring that they have come up, and then login to the IOS

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Kumar McMillan added the comment: fwiw, changing tearDown() so that it executes unconditionally will break a countless number of test suites. No test suite since the dawn of unittest has been designed to tearDown() what may not have been setUp() correctly. in other words, this is how [in my ex

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Jean-Paul Calderone added the comment: /Any/ addCleanup that is successfully executed should cause the cleanup function to be called. Otherwise you have to define all your cleanup twice, and that's no fun. -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: Before I forget though -- should the requirements for the functionality be that it be called strictly in setUp on failure, or should it be executed as a part of tearDown as well? Thanks! -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: Ok, sounds good then ;). I'll open another issue with the enhancement later on this week. Cheers! -- ___ Python tracker ___ ___

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Steve Purcell added the comment: Sounds good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Jean-Paul Calderone added the comment: > And maybe the addCleanup components could be a stack of callable objects? Yea, that's handy. My example didn't show it, but that's what trial implements. -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: And maybe the addCleanup components could be a stack of callable objects? This would make life easier for folks like me and would make the overall flow much cleaner / clearer as it would allow us to break things down into atomic steps which could be reverted in

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Jean-Paul Calderone added the comment: Here's one: class ReactorShutdownInteraction(unittest.TestCase): """Test reactor shutdown interaction""" def setUp(self): """Start a UDP port""" self.server = Server() self.port = reactor.listenUDP(0, self.server, interface

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: I agree with you guys to a certain extent, but doing so only complicates my setup procedure to the extent that I'm calling a lot of my teardown code in a dumb manner, unless I actually kept track of how far into the setup process I got before everything went awr

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Steve Purcell added the comment: Indeed -- if some of the setUp code is likely to fail, that should be handled right there in setUp, by reversing any other setup code that may have executed. It's harder to write a tearDown that will work reliably for any partially successful setUp.

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Raymond Hettinger added the comment: It's up to Steve to decide wheter to commit. I presume that he will want to stay true to JUnit and to avoid risk of breaking existing test suites. -- assignee: -> purcell keywords: +needs review -patch nosy: +purcell, rhettinger __

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: If someone will provide a link to a page with instructions on how to checkout python from cvs / svn / etc I'll gladly apply a patch to the sources on 2.x and 3.x HEAD. Thanks, -Garrett -- ___ Python tracker

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Changes by Garrett Cooper : Removed file: http://bugs.python.org/file13397/issue-blah-2.4.5.diff ___ Python tracker ___ ___ Python-bugs-list ma

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Garrett Cooper added the comment: That patch wasn't complete -_-... here's a more complete 2.4.x patch. -- Added file: http://bugs.python.org/file13398/issue-5538-2.4.5.diff ___ Python tracker _

[issue5538] tearDown in unittest should be executed regardless of result in setUp

Changes by Garrett Cooper : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue5538] tearDown in unittest should be executed regardless of result in setUp

New submission from Garrett Cooper : While trying to deal with some annoying issues with setting up and tearing down consoles via pexpect, I noticed that the teardown functions / methods weren't being executed via nose. After applying this change to 2.4.5 and 2.6.1, things work as expected (note