[issue5679] cleanUp stack for unittest

Ezio Melotti added the comment: Apparently during a merge from trunk (r72477) the addCleanup and other methods ended up in 3.1rc1, even if they are documented as new in 3.2. I'll update the doc to say "new in 3.1". -- nosy: +ezio.melotti ___ Python

[issue5679] cleanUp stack for unittest

Garrett Cooper added the comment: Cool! Thanks for all of the hard work Michael :D. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Committed in revision 72219. -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list ma

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Updated patch with docs. My intention is to apply this in the next couple of days. I've settled on calling doCleanups *after* tearDown. The issues and reasoning explained below. One point of view concerns using addCleanups with existing tests. If the setUp

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sat, 2009-04-25 at 23:17 +, Michael Foord wrote: > Michael Foord added the comment: > > Proper patch and proper issue this time! Not my evening. > > -- > Added file: http://bugs.python.org/file13787/unittest-no-exit.patch Did this want a new i

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Proper patch and proper issue this time! Not my evening. -- Added file: http://bugs.python.org/file13787/unittest-no-exit.patch ___ Python tracker __

[issue5679] cleanUp stack for unittest

Changes by Michael Foord : Removed file: http://bugs.python.org/file13786/unittest-no-exit.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Damn - proper patch without extraneous stuff this time. -- Added file: http://bugs.python.org/file13786/unittest-no-exit.patch ___ Python tracker ___

[issue5679] cleanUp stack for unittest

Jonathan Lange added the comment: FWIW, I kind of like the tests here: http://bazaar.launchpad.net/~jml/testtools/trunk/annotate/head%3A/testtools/tests/test_testtools.py#L221 -- ___ Python tracker

[issue5679] cleanUp stack for unittest

Jonathan Lange added the comment: On Mon, Apr 6, 2009 at 2:16 PM, Kumar McMillan wrote: > > Kumar McMillan added the comment: > > I like this patch.  However, a nice-to-have would be that _doCleanups() > prints a traceback from function(*args, **kwargs) (if there is one) the > same way that at

[issue5679] cleanUp stack for unittest

Kumar McMillan added the comment: I like this patch. However, a nice-to-have would be that _doCleanups() prints a traceback from function(*args, **kwargs) (if there is one) the same way that atexit does. That would aid in debugging mis-written cleanup functions yet would not intrude on your te

[issue5679] cleanUp stack for unittest

Changes by Kumar McMillan : -- nosy: +kumar303 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue5679] cleanUp stack for unittest

Jonathan Lange added the comment: On Mon, Apr 6, 2009 at 10:06 AM, Robert Collins wrote: > On Sun, 2009-04-05 at 23:57 +, Michael Foord wrote: >> Michael Foord added the comment: >> >> My apologies - the jml code on launchpad runs clean ups before taerDown. >> >> http://bazaar.launchpad.ne

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sun, 2009-04-05 at 23:57 +, Michael Foord wrote: > Michael Foord added the comment: > > My apologies - the jml code on launchpad runs clean ups before taerDown. > > http://bazaar.launchpad.net/~jml/testtools/trunk/annotate/head%3A/testtools/testcase.py

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: My apologies - the jml code on launchpad runs clean ups before taerDown. http://bazaar.launchpad.net/~jml/testtools/trunk/annotate/head%3A/testtools/testcase.py -- ___ Python tracker

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sun, 2009-04-05 at 23:49 +, Michael Foord wrote: > > > As an interesting data point, the Bzr code does clean ups *before* > tearDown. No it doesn't: We subclass unittest.TestCase. We also override run() to make tearDown run always. Our base test case

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: @Garrett / Virgil I don't think anything other than very short term confusion is possible. Whichever decision is made a developer who assumes the opposite will actually get an error. In both cases the downside is that in certain circumstances you could attempt t

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sun, 2009-04-05 at 21:31 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > > So, we are talking about adding a feature that could cause problem whether > > cleanup is performed before tearDown or after tearDown. Don't we risk > > confus

[issue5679] cleanUp stack for unittest

Garrett Cooper added the comment: I see the validity in the concern raised by Virgil: I think this can be simplified from a user perspective by saying `I'm electing to use cleanUp over tearDown'. The two systems are similar, but also very different semantically as tearDown gets executed in the

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: This is actually a minor point about the order things happen in. I don't think it will cause confusion in practise once we have made a decision and documented it. Particularly if we decide to call clean ups before tearDown then I will make adding new ones during

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: > So, we are talking about adding a feature that could cause problem whether > cleanup is performed before tearDown or after tearDown. Don't we risk > confusing developers who are not familiar with the cleanup order? Well, we could do both. Call cleanups befo

[issue5679] cleanUp stack for unittest

Virgil Dupras added the comment: So, we are talking about adding a feature that could cause problem whether cleanup is performed before tearDown or after tearDown. Don't we risk confusing developers who are not familiar with the cleanup order? Do we really want to add this feature? The added

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: A use case for running clean ups before tearDown (in which case addCleanUp would need to raise an exception if called during tearDown). You have existing code which (for example) creates an SSH connection in setUp and removes it in tearDown. If clean ups are ru

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: I'm in favour of running clean ups afterwards on the basis that it makes things possible that would otherwise not be possible. > If your cleanup relies on something which has been set up during setUp > and will be dropped during tearDown (a database connection,

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: > I don't understand; neither sequence works > - they are showing how any > choice [that retains the current simple proposed mechanism] cannot > interact without some failure modes with tearDown. And I'm telling you one failure mode is more desireable t

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sun, 2009-04-05 at 10:15 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > > Our experience in bzr (we use this heavily, and migrated to it > > incrementally across our 17K fixture suite) is that we rarely need to > > use cleanups on depe

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: > Our experience in bzr (we use this heavily, and migrated to it > incrementally across our 17K fixture suite) is that we rarely need to > use cleanups on dependent resources, and when we need to it has been > very easy to migrate the dependent resource to use c

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sun, 2009-04-05 at 07:25 +, Garrett Cooper wrote: > Garrett Cooper added the comment: > > I think some perspective is required on this enhancement request. I > originally filed this issue -- http://bugs.python.org/issue5538 -- > because of the unneeded

[issue5679] cleanUp stack for unittest

Garrett Cooper added the comment: I think some perspective is required on this enhancement request. I originally filed this issue -- http://bugs.python.org/issue5538 -- because of the unneeded complexity involved with duplicating teardown-related code in setUp because of a step in setUp failing.

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sat, 2009-04-04 at 23:06 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > > The main use case for addCleanup is resource allocation in tests. Why > > does this require clean ups to be executed before tearDown? > > If your cleanup relies

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: > The main use case for addCleanup is resource allocation in tests. Why > does this require clean ups to be executed before tearDown? If your cleanup relies on something which has been set up during setUp and will be dropped during tearDown (a database connecti

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: The main use case for addCleanup is resource allocation in tests. Why does this require clean ups to be executed before tearDown? -- ___ Python tracker _

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: >def setUp(self): > dirname = mkdtemp() > self.addCleanup(shutils.rmtree, dirname, ignore_errors=True) > db = make_db(dirname) > self.addCleanup(db.tearDown) Sure, but that's an example of doing something which is already doa

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Antoine, Robert suggests calling it after tearDown so that tearDown can also perform actions that need clean up. Not a common use case but at least a use case. What do you mean by: "so that test cases can also use it to initialize additional resources and final

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: On Sat, 2009-04-04 at 22:09 +, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > teardown > > Why should they? It's only an implementation choice, and not a wise one > I would say (precisely because people are used to the fact that the > stand

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: Sorry, roundup screwed the quoting. I was responding to the following sentence: “If you imagine that clean ups are being done in the base class teardown”. -- ___ Python tracker ___

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: teardown Why should they? It's only an implementation choice, and not a wise one I would say (precisely because people are used to the fact that the standard tearDown() method does nothing, and doesn't need to be called). I explained my proposal in terms of ac

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: Actually let me phrase that differently. standard practice for setUp is super.setUp() my_setup_code() and tearDown is my_teardown_code() super.tearDown() because of the LIFO need. If you imagine that clean ups are being done in the base class teardown, at the

[issue5679] cleanUp stack for unittest

Robert Collins added the comment: It should run after tearDown so that teardown can do actions that may require cleanup; because the cleanups run in LIFO you can acquire resources in setUp and have cleanups clean them up, -- nosy: +rbcollins ___ Pyth

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: I'm agnostic on before / after tearDown, so happy to make that change. -- ___ Python tracker ___ ___

[issue5679] cleanUp stack for unittest

Antoine Pitrou added the comment: I'm not sure why it is called after tearDown. It would be better to call it before tearDown, so that test cases can also use it to initialize additional resources and finalize them in a LIFO way wrt the main tearDown. -- nosy: +pitrou _

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: Patch attached. No docs, if it is agreed I can apply I'll write docs. After a long discussion we arrived at some semblance of consensus on the Testing In Python mailing list that this was a good thing (tm). Only one -1 (thought that cleanUp should be a method)

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: And actually your conditionally_undo_setup() call in setUp is incorrect. It should in an except block that re-raises rather than a finally block (which will do the cleanup even in non-exceptional circumstances). Easy code to get wrong... --

[issue5679] cleanUp stack for unittest

Changes by Michael Foord : -- type: behavior -> feature request ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: >From your example this would completely remove the need for the conditional checking in the cleanup code. Only resources actually allocated would be in the stack. -- ___ Python tracker

[issue5679] cleanUp stack for unittest

Michael Foord added the comment: This is a nice (simple to use and understand) pattern for resource allocation / deallocation. Supporting the cleaning up of resources when setUp fails (without duplicating clean up code) is just one use case. (I agree setUp failure is unusual.) It provides a cl

[issue5679] cleanUp stack for unittest

Gregory P. Smith added the comment: I'm used to doing this using a finally clause in the setUp() method (if I do it at all, I'm not used to setUp failing). I guess this would be a convenience to avoid the need for this pattern? I'm not sure we really need a list of cleanup callbacks. Got po

[issue5679] cleanUp stack for unittest

New submission from Michael Foord : Proposal to add a cleanUp stack to unittest.TestCase. This is a list of callables to be called (LIFO) to cleanup resources. If there are items on the stack it should be called even if setUp fails. Otherwise it should be called after tearDown. Similar functiona