[ANN] Test::Unit 0.1.8

ruby-talk
1

If you don’t know what Test::Unit is, I’ve included an explanation
further down. For everyone else, here’s some highlights from the
ChangeLog (you can read the whole thing at
http://testunit.talbott.ws/ChangeLog):

  • Added more output options to the console test runner.
  • Changed Object#id calls to Object#id to remove deprecation
    warnings under 1.7.
  • Did a little performance tuning.
  • Fixed a problem in stack trace filtering in Error.filter.
  • Added the ability to pick the runner when running automatically
    (thanks to Eivind Eklund).
  • Fixed debugging support in unit.rb.
  • Made the failure caused by running an empty suite clear, consistent,
    and changeable.
  • !Removed the return value from Assertions#assert_match.
  • Modified tests to make sure all assertions are returning nil unless
    they’re explicitly supposed to do something else.
  • !Made TestCase#initialize throw :invalid_test if the test method
    specified does not exist (this is in addition to the arity check that
    was already in place).
  • !Changed #assert_match to use #=~ instead of #match; it can now
    handle strings as patterns, too.
  • Fixed warnings under 1.8 caused by not using a 0 before the decimal
    point of floats.

Notes:

  • Test::Unit has been imported in to ruby 1.8. If you’re running
    against the latest CVS, you shouldn’t need to download this!

README:
Unit testing is making waves all over the place, largely due to the fact
that it is a core practice of XP. While XP is great, unit testing has
been around for a long time and has always been a good idea. One of the
keys to good unit testing, though, is not just writing tests, but having
tests. What’s the difference? Well, if you just write a test and throw
it away, you have no guarantee that something won’t change later which
breaks your code. If, on the other hand, you have tests (obviously you
have to write them first), and run them as often as possible, you slowly
build up a wall of things that cannot break without you immediately
knowing about it. This is when unit testing hits its peak usefulness.

Enter Test::Unit, a framework for unit testing in Ruby, helping you to
design, debug and evaluate your code by making it easy to write and have
tests for it.

Grab the fun at http://testunit.talbott.ws/.

Happy testing,

Nathaniel

<:((><

···

RoleModel Software, Inc.
EQUIP VI

2

I’m not familiar with Test::Unit. I’m certainly familiar with software source
comming with a set of tests that you are supposed to run. Is that what this is?

What does this have to do with XP? Do you mean Windows XP? If so, what makes it
different from the test suites that I’ve been using before XP came out?

···

README:
Unit testing is making waves all over the place, largely due to the fact
that it is a core practice of XP. While XP is great, unit testing has
been around for a long time and has always been a good idea. One of the
keys to good unit testing, though, is not just writing tests, but having
tests. What’s the difference? Well, if you just write a test and throw
it away, you have no guarantee that something won’t change later which
breaks your code. If, on the other hand, you have tests (obviously you
have to write them first), and run them as often as possible, you slowly
build up a wall of things that cannot break without you immediately
knowing about it. This is when unit testing hits its peak usefulness.

Enter Test::Unit, a framework for unit testing in Ruby, helping you to
design, debug and evaluate your code by making it easy to write and have
tests for it.

Grab the fun at http://testunit.talbott.ws/.

Happy testing,

Nathaniel

<:((><

RoleModel Software, Inc.
EQUIP VI

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

3

nathaniel@NOSPAMtalbott.ws writes:

If you don’t know what Test::Unit is, I’ve included an explanation
further down. For everyone else, here’s some highlights from the
ChangeLog (you can read the whole thing at
http://testunit.talbott.ws/ChangeLog):

  • Did a little performance tuning.

This is great! In my case, Test::Unit is now only a tiny bit slower
than RubyUnit (still using the RubyUnit compatibility layer). It used
to

I have two suggested patches to the console ui. The “Finished in
seconds” includes to much precision in the seconds (nobody cares
if it finished in 10.3234323 rather than 10.3234322 seconds), and the
console runner never flushes io when it prints out the progress dots
so they don’t function as progress indicators.

— lib/test/unit/ui/console/testrunner.rb Tue Feb 11 21:22:33 2003
+++ /home/matt/pkg/stow/ruby-cvs/lib/ruby/1.8/test/unit/ui/console/testrunner.rbTue Feb 11 23:14:10 2003
@@ -90,7 +90,8 @@

       def finished(elapsed_time)
         nl

  •        output("Finished in #{elapsed_time} seconds.")

  •        output("Finished in %.2f seconds." % 

  •               [ elapsed_time ])
       @faults.each_with_index do |fault, index|
         nl
         output("%3d) %s" % [index + 1, fault.long_display])

@@ -118,7 +119,10 @@
end

       def output_single(something, level=NORMAL)

  •        @io.write(something) if (output?(level))

  •        if (output?(level))

  •          @io.write(something)

  •          @io.flush

  •        end
     end
     
     def output?(level)
···

–
matt

4

What does this have to do with XP? Do you mean Windows XP? If so, what
makes it different from the test suites that I’ve been using before XP came
out?

eXtreme programming-- follow the link below:

http://www.xprogramming.com/xpmag/whatisxp.htm

I’m not familiar with Test::Unit. I’m certainly familiar with software
source comming with a set of tests that you are supposed to run. Is that
what this is?

You’ll notice TDD (Test Driven Development) listed in the list of XP practices
via the link.

Hope this helps-- // Bruce

···

On Tuesday 11 February 2003 11:56 pm, Daniel Carrera wrote:

–
Bruce R. Williams :: [iusris/#ruby-lang] :: http://www.codedbliss.com

‘It does not require a majority to prevail, but rather an irate,
tireless minority keen to set brush fires in people’s minds.’
– Samuel Adams

5

Matt Armstrong wrote:

The “Finished in seconds” includes to much precision in the seconds
(nobody cares if it finished in 10.3234323 rather than 10.3234322 seconds)

Actually I do: that is the only way I can tell that it re-ran sometimes
when I use \C-c \C-c in emacs to re-run the tests. Otherwise, I’ll need
a date stamp or some such.

···

–
Bil Kleb
NASA Langley Research Center
Hampton, Virginia, USA

6

This is great! In my case, Test::Unit is now only a tiny bit
slower than RubyUnit (still using the RubyUnit compatibility
layer). It used to

Was the rest of what you were going to say interesting? :wink:

I have two suggested patches to the console ui. The
“Finished in seconds” includes to much precision in the
seconds (nobody cares if it finished in 10.3234323 rather
than 10.3234322 seconds), and the console runner never
flushes io when it prints out the progress dots so they don’t
function as progress indicators.

Both of these patches will be applied. Thanks!

Nathaniel

<:((><

···

Matt Armstrong [mailto:matt@lickey.com] wrote:

RoleModel Software, Inc.
EQUIP VI

7

Thank-you. I was really confused there.
I’ll read that think. Thanks.

···

On Wed, Feb 12, 2003 at 02:00:38PM +0900, Bruce Williams wrote:

eXtreme programming-- follow the link below:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

8

Matt Armstrong wrote:

The “Finished in seconds” includes to much precision
in the seconds (nobody cares if it finished in 10.3234323
rather than 10.3234322 seconds)

Actually I do: that is the only way I can tell that it re-ran
sometimes when I use \C-c \C-c in emacs to re-run the tests.
Otherwise, I’ll need a date stamp or some such.

Actually, a date/time stamp sounds like the better, more direct solution
here. Added to the TODO.

Nathaniel

<:((><

···

Bil Kleb [mailto:William.L.Kleb@NASA.Gov] wrote:

RoleModel Software, Inc.
EQUIP VI

9

nathaniel@NOSPAMtalbott.ws writes:

···

Matt Armstrong [mailto:matt@lickey.com] wrote:

This is great! In my case, Test::Unit is now only a tiny bit
slower than RubyUnit (still using the RubyUnit compatibility
layer). It used to

Was the rest of what you were going to say interesting? :wink:

It used to be about 100% slower than RubyUnit, now it is only about
30% slower. Very livable – ~20,000 assertions on a 233 MHz Pentium
in 30 seconds (includes my test code running time).

–
matt