Test::Unit 0.1.8 
Author Message
 Test::Unit 0.1.8

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://www.*-*-*.com/ ):

  * 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://www.*-*-*.com/

Happy testing,

Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI



Sun, 31 Jul 2005 12:48:21 GMT  
 Test::Unit 0.1.8
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?

Quote:
> 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


Sun, 31 Jul 2005 12:56:16 GMT  
 Test::Unit 0.1.8

| 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

--
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



Sun, 31 Jul 2005 13:00:38 GMT  
 Test::Unit 0.1.8

Quote:

> eXtreme programming-- follow the link below:

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

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



Sun, 31 Jul 2005 13:03:02 GMT  
 Test::Unit 0.1.8

Quote:

> 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
<foo> 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.r

           def finished(elapsed_time)
             nl
-            output("Finished in #{elapsed_time} seconds.")
+            output("Finished in %.2f seconds." %
+                   [ elapsed_time ])

               nl

           end

           def output_single(something, level=NORMAL)

+            if (output?(level))


+            end
           end

           def output?(level)

--
matt



Sun, 31 Jul 2005 14:21:14 GMT  
 Test::Unit 0.1.8
 > The "Finished in <foo> 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, {*filter*}ia, USA



Sun, 31 Jul 2005 19:36:27 GMT  
 Test::Unit 0.1.8

Quote:


> > The "Finished in <foo> 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

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI



Mon, 01 Aug 2005 11:44:26 GMT  
 Test::Unit 0.1.8

Quote:

> 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? ;-)

Quote:
> I have two suggested patches to the console ui.  The
> "Finished in <foo> 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

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI



Mon, 01 Aug 2005 11:57:01 GMT  
 Test::Unit 0.1.8

Quote:


>> 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



Mon, 01 Aug 2005 17:36:46 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Test::Unit::Mock: Mock objects for testing with Test::Unit

2. using test::unit for C++ unit tests

3. Test order in Test::Unit

4. Test order in Test::Unit

5. MSI-6000 disk test unit in Forth?

6. Test::Unit GUI

7. inifinity recursion && test/unit

8. Test::Unit 0.1.8 reporting problem

9. Test::Unit: assert in loop ?

10. Test::Unit::MockObject not working

11. Need help Translating Python unittest to Ruby Test::Unit

12. Test::Unit VERSION info

 

 
Powered by phpBB® Forum Software