[TIP] cleanUp for unittest

[Marius Gedminas]

I have taken the liberty of refactoring the punctuation in your email.

On Mon, Apr 06, 2009 at 07:27:40AM -0500, Olemis Lang wrote:
> Well, today (Sunday) I finally could read Meszaros' book

That would be "xUnit Test Patterns: Refactoring Test Code" by Gerard
Meszaros, Google tells me.  Looks like an interesting book.

> (did anybody say 2am? what the hell, you're right ;) and identified
> the following patterns to be potentially related with the subject at
> hand 

Thank you.

> (and yes *potentially* means both that I had not enough time to read
> them 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
>   during teardown.

/me wants

> - Delegated Setup (411): Each test creates its own Fresh Fixture by
>   calling Creation Methods from within the Test Methods.

Hey, I've used this!

> - Fresh Fixture (311): Each test constructs its own brand-new test
>   fixture for its own private use.

And this, partially.

> - Garbage-Collected Teardown (500): We let the garbage collection
>   mechanism provided by the programming language clean up after our
>   test.

This sounds like a very bad idea, unless I'm misunderstanding.

> - Test-Specific Subclass (579): We add methods that expose the
>   state or behavior needed by the test to a subclass of the SUT.

Rarely necessary in Python where you can override methods on instances.

> - Testcase Superclass (638): We inherit reusable test-specific logic
>   from an abstract Testcase Superclass.

*nod*

> 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 :
> 
> {{{
> #!python
> 
> class TC(unittest.TestCase)
>     def setUp(self):
>         try:
>             # Allocate resources
>             self.res1 = TheBestResourceEver(*args)
>             self.res2 = DontLetMeDown_Iam_A_Resource(*args)
>             # ... and so on ...
>         except:
>             self.__dict__.clear()

-1

This relies on Python's garbage collector implementation details (i.e.
refcounting), and assumes self is the only place that holds references
to the resource proxies (which is sensible, if you write proxies
specifically for this purpose).

>             raise
> }}}
> 
>   ... should be enough (otherwise I wanna know)

See above.

>   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 ... ;)

If the garbage collector's __del__ semantics aren't bizarre and
complicated for you, I'd hate to see what is ;-)

> - 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're talking about in here. I dont think that modifying
> TestCase is the right approach ... *at all*.

Many of the patterns are things that cannot be implemented in a library.
Those that can... what are the advantages of providing them separately
instead of enhancing TestCase?

> 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're very talkative here ... that's ok, but I have no time to
> follow all this. I apologize if I'm missing something you've already
> said

;-)

I've only very recently subscribed to this list, but I have the
impression that the current volume of discussion is not typical.

Marius Gedminas
-- 
Bumper sticker: If you can read this, I can hit my brakes and sue you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20090407/ab2d543f/attachment-0001.pgp