On Mar 30, 2004, at 20:29, Mike Iles wrote:

> (Apologies if this is an obvious question, I'm new to Ruby.)

No apology necessary... and welcome :-)


> I'm setting up a unit testing framework for a project here and I'm
> loving what I see in Ruby so far. I have one problem though:
>
> I have a large number of test cases which all share common setup and
> teardown logic (starting and stopping external processes). To do this
> I've subclassed Test::Unit::TestCase and all of my project test cases
> then derive from this new class. This allows me to override the setup
> and teardown methods to do what I want.
>
> This works wonderfully, except that one *additional* test is always run
> and this test always fails saying that "No tests were specified".
>
> I'm hypothesizing that the unit testing framework is scanning the
> ObjectSpace to find all classes that subclass Test::Unit::TestCase and
> in addition to the real test cases it's also finding my intermediate
> class, which indeed contains no tests.

Your hypothesis is exactly correct.


> I'm currently working around this by also overriding default_test in 
> the
> intermediate class and doing nothing, which causes this superfluous 
> test
> to pass, but it skews the numbers and I would like a cleaner approach.

This is one of the two solutions that I'd recommend. Does it really 
skew the numbers that badly? I think it only adds one extra test to the 
run.


> It would be nice if the unit testing framework didn't automatically
> insert default_test into the list of tests to be run, but changing the
> source (testcase.rb) is an unappealing option because this unit testing
> setup will be run by many of the developers here and I don't want to
> have to patch their installations by hand.

Yah, I definitely wouldn't recommend that. As for not having 
default_test run, well, that was hashed out here on ruby-talk quite a 
while ago. I'm pretty firmly set on keeping it the way it is.


> I imagine that I could override self.suite in some way to avoid the use
> of default_test.

That might be possible, but I'm not sure it would be worth it.


> I could probably also avoid the use of my intermediate
> class altogether by somehow using mixins. (I anticipate that using
> mixins to replace existing methods would be tricky.)

Actually, this is my favorite solution out of the two I recommend. It's 
really not very tricky at all... I'd bet you can transform your code 
very quickly and with a minimum of hassle. I'm amazed at how 
intuitively the mixin mechanism works - I regularly run up against a 
problem and go, "I'd like to do this with a module, but I bet it won't 
work very well..." and then I try it, and it works beautifully.

Try it, I bet you'll like it.


> Can anyone help guide me through this?

I hope I've been able to help... there are also a few more thoughts in 
this thread:

   http://www.ruby-talk.org/blade/76201.


Again, welcome to Ruby... I hope you enjoy your time here!


Nathaniel
Terralien, Inc.

<:((><