[TIP] cleanUp for unittest
olemis at gmail.com
Mon Apr 6 05:27:40 PDT 2009
Firstly I'll correct something ...
On Fri, Apr 3, 2009 at 3:23 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Fri, Apr 3, 2009 at 3:03 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>> o Lang wrote:
>>> For example other useful use cases really included in XUnit framews are :
>>> - Test decorators ...
>>> I think we should have more of these instead of modifying
>>> unittest.TestCase for this feature ...
>> Totally new subject
> there is even a test decorator in dutest itself ... PackageTestLoader ... ;)
Well ... what I said here is not accurate ... this is a case
where decorator pattern has been applied to a TestLoader not a test
case. Let's say that I was busy, hurry, completely drunk, thinking I was
at a tropical beach, drinking piña colada, surrounded by beatiful
women ... and Britney wispering in my ear ... I'm sure you'll
understand my position here and forgive my ... distraction ... :^D
Up to this time there is no test decorator in dutest ... but I have
plans (not the time ... :-/ ...) to include'em ...
On Sat, Apr 4, 2009 at 11:23 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> I've written a patch that implements this:
> Comments on code or supporting comments on the issue welcomed. ;-)
I saw this ... I dont know if I have to say this here or submit a
comment to the entry in the issue tracker ... I hope you dont mind to
see this message in your inbox. Here it goes :
Well, today (sunday ) I finally could read Meszaros' book ... (did anybody say
2am ? ... what t(he)ll u'r right ;) ... and identified the following
patterns to be potentially related with the subject at hand (and yes
*potentially* means both : I had not enough time to read'em all and
analyze what they do in detail, and besides it is also possible that
I'd be missing a useful pattern ... ):
- Automated Teardown (503): We keep track of all resources that are
created in a test and automatically destroy/free them
- Delegated Setup (411): Each test creates its own Fresh Fixture by
calling Creation Methods from within the Test Methods.
- Fresh Fixture (311): Each test constructs its own brand-new test
fixture for its own private use.
- Garbage-Collected Teardown (500): We let the garbage collection
mechanism provided by the programming language clean up after our
- Test-Specifi c Subclass (579): We add methods that expose the
state or behavior needed by the test to a subclass of the SUT.
- Testcase Superclass (638): We inherit reusable test-specific logic
from an abstract Testcase Superclass.
My impresions (oh! Britney! go away! just a minute ... XD) :
- Garbage-Collected Teardown gave me a idea (perhaps not related with
the pattern itself ... but close enough ;) to solve the problem
at hand. Implement «proxy objects» to allocate and
provide access to the resources. Resource allocation in that case
consists of creating these proxy objects, immediately (or lazily ;)
binding the test resources to them. If a failure is detected, the
following simple construct :
# Allocate resources ...
self.res1 = TheBestResourceEver(*args)
self.res2 = DontLetMeDown_Iam_A_Resource(*args)
# ... and so on ...
... should be enough (otherwise I wanna know ...)
provided that the proxy object deallocates
(explicit|implicit)ly the resources bound to it, if any, once the
garbage collector is doing its job (override the proxy's __del__
method ;). All this happens due to the fact that clearing the
mapping object leaves'em un-referenced. Oh ! yes ... I know ...
no list, no registering infrastructure, no iteration, no bizarre
semantics and complicated understanding | interactions ... ;)
- Automated Teardown is a little bit more complicated than the
former. In this case there is an external «Test Object Registry».
It is there just to track the resources being allocated so far at
testing-time. Either on failure during setUp, or inside tearDown,
the registry is contacted so as to clear them all ... AYCS in this
case the implementation employs an external object (mediator ?,
repository ?, this is actually one of the approaches I told you
already ;) which takes care of tracking resource allocation. How
implicit | explicit this should | may | can be done considering the
tools we have at hand in Python, whether sub-classing is better or
not ... well that's another debate ... I only wanted to add that
having a central object coordinating all this prevents scattering
... an ally of chaos thus an enemy of coders =|;^)X-
In fact the motivation for this testing pattern is pretty close to
the original problem statement ...
In general my impression and desire is that a comprehensive, wonderful
library of xUnit testing patterns needs to be created (... placed in
stdlib ? ) for Py ... and one of those patterns should address the
situation we 'r talking about in here. I dont think that modifying
TestCase is the right approach ... *at all*.
If there are enough hands to build such libs, count on me ... S;^)x-
I invite you all to read Meszaros' book to find out further details.
And you know, if you find further useful comments, well, I'd like to
know ... share'em pls ... :P
PS: About the hints ... remember Britney ... those above are simply
random thoughts ... :P
I see you'r very talkative here ... that's ok, but I have no time to
follow all this. I apologize if I'm missing somethin' you've already
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
More information about the testing-in-python