Subclassing Test::Unit::TestCase

Hi,

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

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.

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.

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.

I imagine that I could override self.suite in some way to avoid the use
of default_test. 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.)

Can anyone help guide me through this?

Thanks,
Mike.

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

No apology necessary… and welcome :slight_smile:

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.

<:((><

···

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