[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

unit test

Brian Buckley

5/6/2005 1:05:00 PM

Hello all,

In the code below the first test by itself passes. However, when I add a
second test called "test_bad_data", the first test fails. The method count
on BigDecimal apppears to change from 82 to 86.

I've noticed that if I give "test_bad_data" a different test name (but still
starting with "test_") all works as expected.

What's happening?

Brian

-----------------------------------------
require 'test/unit'
require 'bigdecimal'

class TestBigDecimal < Test::Unit::TestCase
def test_method_count
assert_equal 82, BigDecimal.methods.size
end

def test_bad_data
assert_equal "", "0.0" #causes first test to fail
end

end
5 Answers

Nathaniel Talbott

5/6/2005 2:01:00 PM

0

Brian Buckley wrote:

> In the code below the first test by itself passes. However, when I add a
> second test called "test_bad_data", the first test fails. The method count
> on BigDecimal apppears to change from 82 to 86.
>
> I've noticed that if I give "test_bad_data" a different test name (but still
> starting with "test_") all works as expected.
>
> What's happening?

I'm not sure, since I can't reproduce the problem:

t.rb:
require 'test/unit'
require 'bigdecimal'

$include_bad_data = ARGV[0]

class TestBigDecimal < Test::Unit::TestCase
def test_method_count
assert_equal 83, BigDecimal.methods.size
end

if($include_bad_data)
def test_bad_data
assert_equal "", "0.0" #causes first test to fail
end
end
end

Output:

C:\TEMP>ruby -v t.rb
ruby 1.8.2 (2005-04-21) [i386-mswin32]
Loaded suite t
Started
.
Finished in 0.0 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

C:\TEMP>ruby -v t.rb -- a
ruby 1.8.2 (2005-04-21) [i386-mswin32]
Loaded suite t
Started
F.
Finished in 0.0 seconds.

1) Failure:
test_bad_data(TestBigDecimal) [t.rb:14]:
<""> expected but was
<"0.0">.

2 tests, 2 assertions, 1 failures, 0 errors


Seems normal to me... now I am running a stable snapshot, and had a
different number of initial methods in BigDecimal... what version of
Ruby are you seeing this behavior on?


--
Nathaniel

<:((><

Brian Buckley

5/6/2005 2:36:00 PM

0

Nathaniel,

I'm 1.8.2 (2005-04-21) [i386-mswin32] also. Windows XP.

I'm not sufficiently familiar with ruby -- might there be custom settings
that I am setting on my box which aren't on yours? (ruby's equivalent to
java's classpath? loadpath?)

And one more piece of diagnosis info: the code below shows the four methods
that are being added (It still doesn't explain why this only happens to me
when using the name "test_bad_data" or why our method counts are off - 83 vs
82)

Any suggestions?

Brian

---------------------------------

class TestBigDecimal < Test::Unit::TestCase

def test_method_count

b = BigDecimal.methods
assert_equal 82, b.size

assert_raise(Test::Unit::AssertionFailedError) do
assert_equal "0.0", "0.x"
end

a = BigDecimal.methods
assert_equal 86, a.size

assert_equal a - b,
["pretty_print_cycle",
"pretty_print_inspect",
"pretty_print",
"pretty_print_instance_variables"]
end

end

Brian Buckley

5/6/2005 2:47:00 PM

0

Oops - hang on - I'm on 1.8.2 (2004-12-25) [i386-mswin32]. I'm guessing that
explains the one-method-off part. -Brian

Caleb Tennis

5/6/2005 3:00:00 PM

0

> And one more piece of diagnosis info: the code below shows the four
> methods
> that are being added (It still doesn't explain why this only happens to me
> when using the name "test_bad_data" or why our method counts are off - 83
> vs
> 82)

One thing of note: the test cases are (at least here) executed in
alphabetical order, not in the order they are defined in. Your
"test_bad_data" is probably getting run first, and modifying something
that is changing how one of your later test cases is running.

Nathaniel Talbott

5/6/2005 4:09:00 PM

0

Brian Buckley wrote:

> I'm not sufficiently familiar with ruby -- might there be custom settings
> that I am setting on my box which aren't on yours? (ruby's equivalent to
> java's classpath? loadpath?)
>
> And one more piece of diagnosis info: the code below shows the four methods
> that are being added (It still doesn't explain why this only happens to me
> when using the name "test_bad_data" or why our method counts are off - 83 vs
> 82)
>
> Any suggestions?

<snip>

> ["pretty_print_cycle",
> "pretty_print_inspect",
> "pretty_print",
> "pretty_print_instance_variables"]

OK, I know what's going on now. 'pp' (PrettyPrint) adds those four
methods to Object (or Kernel, I can't remember) when it's required, and
test/unit requires pp when it builds the message for the failed
assertion. The reason I wasn't seeing my methods go up is because when I
wrote my little test program, I was requiring pp at the top, thus the
methods were already there. The funny thing is I deleted that line
before posting, thinking, "Awwww, it won't matter".

You have three options: explicitly require pp, disable the use of pp by
test/unit (Test::Unit::Assertions.use_pp = false), or change your code
so that it doesn't care. I'd favor the last option, since Ruby's dynamic
nature makes a method count extremely brittle. Perhaps you could
explicitly check for methods you expect to be there, or better yet,
whether the object you're testing #responds_to? the methods of interest?

HTH,


--
Nathaniel

<:((><