How do I patch Test::Unit?

Ruby
1

I’ve finally found some time to dig into one of my favorite parts of
Ruby, the Test::Unit module. I have some ideas for how to enhance it
a bit.

First I just wanted to do a sanity check that I can make changes and
see the effects. For some reason, no matter what I modify in my
Test::Unit source code, my changes don’t seem to take effect.

For example, if I found unit.rb and added a puts statement:

at_exit do
unless $! || Test::Unit.run?
puts “HELLO THERE!”
exit Test::Unit::AutoRunner.run
end
end

but when I run my test (a simple ruby file that requires test/unit), I
don’t see “HELLO THERE!”.

I also tried just reopening the class right above my test class
definition:

module Test
module Unit
module UI
module Console

    # Runs a Test::Unit::TestSuite on the console.
    class TestRunner
      def start
        output "Hello There!"
        setup_mediator
        attach_to_mediator
        return start_mediator
      end
    end
  end
end

end
end

and still nothing.

What am I doing wrong?

Oh, ruby -v reports:
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]

Thanks
Jeff

2

Perhaps my original post was too long or too obtuse… let me
rephrase.

What’s the best way to extend then test/unit classes?

Thanks
Jeff

3

On Sep 17, 11:50 am, Jay L. [email protected] wrote:

Remember that the Mac comes with an old Ruby (1.8.2?) in /usr/bin, and
therefore probably an old Test::Unit in /usr/lib. Make sure you’re not
picking that up via $PATH; might just wanna delete it.

So it turns out that although I thought was saving my edits to
unit.rb, in fact there was a permissions problem and TextMate wasn’t
actually saving it.

Your idea about checking the path helped me figure it out.

Thanks.
Jeff

4

Jeff,

I just tested the change to unit.rb that you mentioned, and it had the
expected effect (printing “Hello there”). So I would make sure you’re
editing the right file. If you are sure you are editing the right file,
but still cannot get any result, try deleting it – then you’ll know for
sure whether that file is being used.

As for not being able to edit the (open) classes, make sure you are
editing the classes after you require the files, otherwise your changes
will be overwritten. Also be very careful about namespaces / modules and
such. I suggest not using any “include” statements, because they might
introduce ambiguity. The important thing is that when you make a change
to the class in question, you are changing the right class (and not just
making a new one). When I ran “irb -r ‘test/unit’”, I found that the
module Test::Unit::UI existed, but Test::Unit::UI::Console did not, so
that might be your problem. (I just tested with “puts”.)

Finally, for which strategy you should use to extend these tools:
-If your end goal is to make changes that you want distributed with the
ruby standard library, you might as well patch the source directly.
-If you intend to distribute your code as a library or gem, you had
better reopen the class in a different file (not patch unit.rb), because
it would be rude to ask users to make that change for the sake of your
program. After all, it could break other programs.
-If this is purely for personal use, you may do whichever is easier. The
second way leaves you less likely to accidentally cripple your Ruby
distribution.

Hope this helps,
Dan

5

On Sep 16, 9:05 pm, Dan Z. [email protected] wrote:

Jeff,

I just tested the change to unit.rb that you mentioned, and it had the
expected effect (printing “Hello there”). So I would make sure you’re
editing the right file. If you are sure you are editing the right file,
but still cannot get any result, try deleting it – then you’ll know for
sure whether that file is being used.

Thanks a lot, Dan. When you said this, it caused me to try the same
thing on my Windows box, and it worked. So now I suspect it’s
something about the way I’ve compiled/setup Ruby on my Mac laptop.

As for not being able to edit the (open) classes, make sure you are
editing the classes after you require the files, otherwise your changes
will be overwritten. Also be very careful about namespaces / modules and
such. I suggest not using any “include” statements, because they might
introduce ambiguity. The important thing is that when you make a change
to the class in question, you are changing the right class (and not just
making a new one). When I ran “irb -r ‘test/unit’”, I found that the
module Test::Unit::UI existed, but Test::Unit::UI::Console did not, so
that might be your problem. (I just tested with “puts”.)

Interesting, I’ll be sure to watch out for these.

Finally, for which strategy you should use to extend these tools:
-If your end goal is to make changes that you want distributed with the
ruby standard library, you might as well patch the source directly.
-If you intend to distribute your code as a library or gem, you had
better reopen the class in a different file (not patch unit.rb), because
it would be rude to ask users to make that change for the sake of your
program. After all, it could break other programs.
-If this is purely for personal use, you may do whichever is easier. The
second way leaves you less likely to accidentally cripple your Ruby
distribution.

Exactly - I’m hoping to distribute a library to our Ruby teams at
work, so I’ll be re-opening the classes.

Hope this helps,
Dan

It does! Thansk again. Maybe I’ll post again if I can find out what
I’m doing wrong on my Mac environment.

Jeff

6

On Mon, 17 Sep 2007 13:13:01 +0900, Jeff wrote:

Thanks a lot, Dan. When you said this, it caused me to try the same
thing on my Windows box, and it worked. So now I suspect it’s
something about the way I’ve compiled/setup Ruby on my Mac laptop.

Remember that the Mac comes with an old Ruby (1.8.2?) in /usr/bin, and
therefore probably an old Test::Unit in /usr/lib. Make sure you’re not
picking that up via $PATH; might just wanna delete it.