[ANN] Test::Unit 0.1.8

Nathaniel_Talbott · 12 February 2003 04:48

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

Daniel_Carrera · 12 February 2003 04:56

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

Matt_Armstrong · 12 February 2003 06:21

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

Bruce_Williams · 12 February 2003 05:00

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

Bil_Kleb3 · 12 February 2003 11:36

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

Nathaniel_Talbott · 13 February 2003 03:57

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?

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

Daniel_Carrera · 12 February 2003 05:03

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

Nathaniel_Talbott · 13 February 2003 03:44

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

Matt_Armstrong · 13 February 2003 09:36

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?

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

Topic		Replies	Views
[ANN] Test::Unit 0.1.6 ruby-talk	7	116	16 January 2003
[ANN] Test::Unit 0.1.5 ruby-talk	23	152	29 December 2002
[ANN] test-unit 2.0.1 Released ruby-talk	0	121	9 November 2008
Problems with Test::Unit and Ruby 1.8? ruby-talk	0	99	4 May 2003
Problems with TestUnit ruby-talk	5	68	5 December 2003

[ANN] Test::Unit 0.1.8

Related topics