From: Richard <RichardDummyMailbox58407@...>
Date: 2006-12-06T13:45:06+09:00
Subject: Re: Why does a test fail when I predicted it's exception class?

Hi Erik,

Hi Eric,

> Using #setup and #teardown its easy to avoid the need to number tests.

Thanks for mentioning them.

> The only restrictions test/unit has are that the must start with
> 'test' and accept 0 arguments.
Excellent

> I match test methods to implementation methods and test classes to
> implementation classes.  This allows easy auditing [snip]
I like that, too.

> And everything stays in run order.
Ah, that's what I didn't know.  I thought my numbering might be
required to achieve that.

> I don't care, they're your tests [snip]
Great.

> >> $ ruby test_polish.rb -n /eval/
> > Do you have any idea why the command with the "-n" switch failed on my
> > system?  My code follows.
>
> Try again running your test file :)
Woops!

Your answers here solved a problem I posted yesterday about another
messed up test. I have now deleted that post because "I've seen the
light."

Below is a toy testing setup.  I stuck with my numbered approach for
the moment because it fit these tests.  This setup worked quite nicely.
If you're in the mood to comment on them,  I'd be a grateful recipient.
 But I think I'm OK on this topic now.  Incidentally,  I thought about
trying to use lamda expressions to reduce the duplication, but enough
is enough.

Again, thank you for providing such thoughtful comments.

Best wishes,
Richard

SetupTeardown.rb
=============
class Foo
  MyConst = "Foo's Constant"
  def initialize(n)
	@n = n
  end
  def bar
      "I'm Foo#bar with #{MyConst}#{@n}"
  end
end

puts Foo.new(1).bar if __FILE__ == $0

TestSetupTeardown.rb
================
# "TestSetupTeardown"

require 'test/unit'
require 'tc_Test1'

tc_Test.rb
========
require './SetupTeardown'
require 'test/unit'
class TestST < Test::Unit::TestCase
  def setup
	@instance1 = Foo.new(1)
	@instance2 = Foo.new(2)
  end
  def teardown
	@instance1  = nil
	@instance2  = nil
  end
  def test1
    assert_equal("I'm Foo#bar with Foo's Constant1",
	    @instance1.bar)
    assert_equal("I'm Foo#bar with Foo's Constant2",
	    @instance2.bar)
  end
end

Result (using SciTE)
=====
>ruby TestSetupTeardown.rb
Loaded suite TestSetupTeardown
Started
.
Finished in 0.0 seconds.

1 tests, 2 assertions, 0 failures, 0 errors
>Exit code: 0


Eric Hodel wrote:
> On Dec 3, 2006, at 15:55 , Richard wrote:
>
> >> def test_eval_bad_operator
> > 1.  I take it that to conform to unit-test's expectations,  the test
> > names should begin with test_ and not test1_, test2_ etc.
>
> Numbering tests is not typical behavior (I've seen it very rarely).
> Using #setup and #teardown its easy to avoid the need to number tests.
>
> The only restrictions test/unit has are that the must start with
> 'test' and accept 0 arguments.
>
> > 2.  How about me using test_1_Whatever, test_2_SomethingElse, etc,?
> > Wouldn't that conform equally well and cause any error msgs
> > produced by
> > Test to be presented in lexicographical order (with fewer than 10
> > tests; double digits if I wanted up to 99 tests, etc.)?
>
> I match test methods to implementation methods and test classes to
> implementation classes.  This allows easy auditing (for example with
> ZenTest) or even visually of your test coverage.
>
>    def test_foo() end
>
> matches
>
>    def foo() end
>
> and if I need to test a couple edge-cases of foo:
>
> def test_foo_empty_foopy() end
> def test_foo_no_blah() end
>
> And everything stays in run order.
>
> > 3.  I like to produce tests in one-line format if they'll fit on my
> > screen reasonably so that I can write and scan them more quickly.  Do
> > see any substantive problem in my continuing to do that?
>
> I don't care, they're your tests (but I hate ; so I had to get rid of
> them.)
>
> I sometimes write:
>
>    def some_method() do_the_stuff end
>
> because the ; is ugly, but almost always for test stub objects.
>
> Most people add newlines.
>
> >> $ ruby test_polish.rb -n /eval/
> >
> > I'm running Ruby_1.8.2-15 over WinXP-Pro/SP2.  I tried this command
> > and
> > got nothing:
> >
> > === Command Window ====
> > K:\_Projects\Ruby\TestUnitTesting\ReversePolishEvaluator>ruby
> > RevPolishEvaluator.rb -n /eval/
> >
> > K:\_Projects\Ruby\TestUnitTesting\ReversePolishEvaluator>
> > ====== end ============
> >
> > I thought the problem might be that I had no errors, so that there was
> > nothing for Test to report.  So I introduced an erroneous assertion
> > (expressed  in three lines rather than my preferred one-line format)
> > but still got nothing.
>
> You ran your implementation, not your tests.
>
> > Then I ran this expanded test through SciTE and got (both in one-line
> > format as well as three-line format):
> >
> > ==== SciTE output ====
> >> ruby RevPolishEvaluatorTest.rb
> > Loaded suite RevPolishEvaluatorTest
> > Started
> > .............F....
> > Finished in 0.031 seconds.
>
> This one ran with -n
>
> > Do you have any idea why the command with the "-n" switch failed on my
> > system?  My code follows.
>
> Try again running your test file :)
>
> > Again,  thanks for your suggestions.  I look forward to your comments.
>
> Oh, also you can make your test shorter with setup:
>
> > === tc_TestSet2.rb ===
> >  require '.\RevPolishEvaluator.rb'
> >
> > class ErrorTests < Test::Unit::TestCase # The succinct way
>
> def setup() @p = Polish.new end
>
> > def test_1_noarg; assert_raise(ArgumentError) {Polish.new().eval}; end
>
>    def test_1_noarg() assert_raise ArgumentError do @p.eval end end
>
> (As you can see, I hate punctuation.)
>
> --
> Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
> 
> I LIT YOUR GEM ON FIRE!