Testunit message override?

If this assert fails:

    assert_equal(Date.new(2006,4,15), calc.disbursal_date)

it prints something like:

test_PayFifteenthAfterQuarter(ProjectTest) [./projecttest.rb:13]:
<#<Date: 4907679/2,0,2299161>> expected but was
<#<Date: 4907681/2,0,2299161>>.

With the dates in a rather odd format, as you see above. Yet Date’s to_s
method
is perfectly reasonable.

I looked in the TestUnit docs for AssertionMessage, called by
build_message, but
if it’s in there I couldn’t find it.

If I ever knew how to override TestUnit’s printing, I’ve forgotten how.
Please
remind me what’s going on or point me to it.

Thanks,

Ron J. wrote:

/ …

If I ever knew how to override TestUnit’s printing, I’ve forgotten how.
Please remind me what’s going on or point me to it.

Have you printed out both the test date and the source date, to see how
they
look to the eye? If neither date produces an error this way, it’s hard
to
see how they could do so in a test suite.

On Sep 20, 2006, at 8:20 PM, Ron J. wrote:

If this assert fails:

    assert_equal(Date.new(2006,4,15), calc.disbursal_date)

Not sure if this answers your question, but you can provide a
replacement message as a third parameter.

Hope that helps.

James Edward G. II

On Thu, Sep 21, 2006 at 10:20:06AM +0900, Ron J. wrote:

With the dates in a rather odd format, as you see above. Yet Date’s to_s method
is perfectly reasonable.

It’s not calling Date#to_s, it’s calling Date#inspect. I think you can
do:
assert_equal( a = Date.new(2006, 4, 15), b = calc.disbursal_date,
“Expected Date of #{a}, got date of #{b}”)

From: “Logan C.” [email protected]

<#<Date: 4907681/2,0,2299161>>.

With the dates in a rather odd format, as you see above. Yet Date’s to_s method
is perfectly reasonable.

It’s not calling Date#to_s, it’s calling Date#inspect. I think you can
do:
assert_equal( a = Date.new(2006, 4, 15), b = calc.disbursal_date,
“Expected Date of #{a}, got date of #{b}”)

Alternately,

class Date
alias_method :inspect, :to_s
end

…to replace the old :inspect with :to_s.

Regards,

Bill

On Thu, 21 Sep 2006 11:20:36 +0900, Logan C.
[email protected]
wrote:

With the dates in a rather odd format, as you see above. Yet Date’s to_s method
is perfectly reasonable.

It’s not calling Date#to_s, it’s calling Date#inspect. I think you can
do:
assert_equal( a = Date.new(2006, 4, 15), b = calc.disbursal_date,
“Expected Date of #{a}, got date of #{b}”)

Ah. #inspect. I did know the trick of the message parm, but it still
prints the
inspect anyway. I would have liked to be rid of it, or to have the code
call
to_s. I suppose I could override inspect if I really care.

Thanks!

On Thu, 21 Sep 2006 12:11:31 +0900, “Bill K.” [email protected] wrote:

Alternately,

class Date
alias_method :inspect, :to_s
end

…to replace the old :inspect with :to_s.

I just might. Thanks!

Bill K. wrote:

class Date
alias_method :inspect, :to_s
alias inspect to_s # alternately
end

Devin

On Sep 21, 2006, at 6:55 PM, Ron J. wrote:

do:
assert_equal( a = Date.new(2006, 4, 15), b = calc.disbursal_date,
“Expected Date of #{a}, got date of #{b}”)

Ah. #inspect. I did know the trick of the message parm, but it
still prints the
inspect anyway. I would have liked to be rid of it, or to have the
code call
to_s. I suppose I could override inspect if I really care.

The message will use to_s, but without it, assert_equal and friends
will use inspect. I don’t like Date’s inspect either so I’ll often
assert_equal against the #to_i results instead. That way it is
obvious if I’m off by +/- 1 or my code is just plain wack.

(oh, and hi Ron… long time!)

On Fri, 22 Sep 2006 11:43:18 +0900, Ryan D.
[email protected] wrote:

The message will use to_s, but without it, assert_equal and friends
will use inspect. I don’t like Date’s inspect either so I’ll often
assert_equal against the #to_i results instead. That way it is
obvious if I’m off by +/- 1 or my code is just plain wack.

Yes. I preferred the date format for my purposes, and wasn’t aware that
it was
inspect that was being used.

(oh, and hi Ron… long time!)

Hi back!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs