[TIP] cleanUp for unittest

[Olemis Lang]

On Tue, Apr 7, 2009 at 9:52 AM, Marius Gedminas <marius at gedmin.as> wrote:
> I have taken the liberty of refactoring the punctuation in your email.
>

Oh ! yes. I started using this software for that
   _
  (<  ............................................ (PacMan, if you
dont get the idea :)

Seriously, that's ok. I refactored what I said in my previous message ;)

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

:)

You may also want to check out their online catalog [1]_ ;) They even
have categories

=:O

>> - Automated Teardown (503):
[...]
>
> /me wants
>

c here [2]_

>> - Delegated Setup (411):
[...]
>
> Hey, I've used this!
>

:)

>> - Fresh Fixture (311):
>
> 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.

Possibly, it's always up to the tester whether he/she uses or not ;)

>> - 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),

That's th idea ;)

> and assumes self is the only place that holds references
> to the resource proxies

I think I can make such a supposition in here since :

- I just created the resource proxies in the body of the try
statement, so the only reference in this case is held by self.__dict__
.

- As I said, the semantics for resource proxies is that they control
access to the underlying resource as long as they are loaded in
memory. If you want to discard'em call (force?) GC .

- If you want to control shared access to your resources, then it is
very posible that you might want to use either GoF Singleton or
ParametricSingleton pattern to implement the proxy classes ( there is
actually an article in JOT about using ParametricSingleton to control
access to shared RMI registries ;)

Otherwise, I'd like to know where this fails ;)

> (which is sensible, if you write proxies
> specifically for this purpose).
>

Why ? Dont c it ... turn on the lights pls ! :)

>>             raise
>> }}}


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

Maybe. Dont know about that pattern that much :-/

>> - Testcase Superclass (638): We inherit reusable test-specific logic
>>   from an abstract Testcase Superclass.
>
> *nod*
>
>>   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 ;-)
>

Well, maybe. Indeed I was thinking about, if the object has no
references let GC do its own work (no matter what he does), and keep
your test code simple.

>> - Automated Teardown is a little bit more complicated than the
>>   former.
[...]
>
>> 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.

Yep. The same happens with design patterns ;)

> Those that can... what are the advantages of providing them separately
> instead of enhancing TestCase?
>

- Not everybody uses'em all all the time

- With time many (and I mean many ;) patterns can show up ... and
monolithic approaches dont scale ... That's what inheritance is there
for

- The case for the monolithic approach of adopting the
«one-class-to-do-it-all» goes even against patterns, which promote
collaboration and flexibility, and are based on collaboration,

- XUnit itself is described & designed using  a collaboration-centric
approach [3]_. Refusing to c that is IMHO an error  ;)

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

Yep, it seems we 'r ... in action !

:)

.. [1] XUnit patterns
        (http://xunitpatterns.com/)

.. [2] Automated Teardown
        (http://xunitpatterns.com/Automated%20Teardown.html)

.. [3] JUnit 3.8 Documented Using Collaborations
        Dirk Riehle,
        ACM SIGSOFT Software Engineering Notes pp. 1 March 2008, Vol 33 No 2
        (http://www.riehle.org/wp-content/uploads/2008/04/sen-2008-03-junit-doc.pdf)

-- 
Regards,

Olemis.

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

Featured article:
Se retira el BDFL ... ¿El fin de Python 3k?