[TIP] cleanUp for unittest

Olemis Lang 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 ...

Secondly ...

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:
>
> http://bugs.python.org/issue5679
>
> 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
  during teardown.
- 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.
- 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 :

{{{
#!python

class TC(unittest.TestCase)
    def setUp
        try:
            # Allocate resources ...
            self.res1 = TheBestResourceEver(*args)
            self.res2 = DontLetMeDown_Iam_A_Resource(*args)
            # ... and so on ...
        except:
            self.__dict__.clear()
            raise
}}}

  ... 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
said

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:



More information about the testing-in-python mailing list