From: sera@... (Francis Hwang)
Date: 2003-12-11T16:07:01+09:00
Subject: Re: How to unit test finalizers?

I never solved this one, myself. I just ended up having the finalizer
call another method, and then unit-testing that method -- a bit of a
hack, but I suppose it's better than nothing.

For the most part finalizers aren't really necessary since the block
syntax of Ruby makes it easy to handle resource creation and
destruction in the same method. If your syntax looks like

someObject.getResource { |resource| resource.doThing }

.... then all you have to do is ensure that the getResource method
cleans up after itself. This works very well for self-contained
resources. It doesn't work well for resources that might be invoked
from a million different points in an application. This is the
situation with Lafcadio: it's managing a DB connection that you want
to only create once per process, but there's no guarantee it'll be
told accurately when to let go of its resources. (Part of the appeal,
in my mind, of DB abstraction is getting to think less about that.)

Francis


Samuel Tesla <samuel@thoughtlocker.net> wrote in message news:<87ekvcpjrv.fsf_-_@hiro.int.procacious.com>...
> matz@ruby-lang.org (Yukihiro Matsumoto) writes:
> 
> > Nothing.  There's no way to "ensure" instance to be GC'ed except for
> > program termination.  That's a weak (or charm) point of Ruby's GC.
> 
> That's fine.  I'm guessing that the GC will eventually, most likely,
> collect those references.  The question then becomes, how can I
> reliably unit test my finalizer code if I can't reliably get it to
> execute?
> 
> Any ideas?
> 
> Thanks,
> Samuel