Changing Test::Unit::Assertion messages

C

Curt Sampson

In many of my tests, I do something along the lines of

assert_match(/foobar/, content)

When the assertion fails, it prints out something resembling the
inspect of the content. In some cases, it's much more readable to print
something different. How do I do that for this one case, but leave the
default behaviour for other cases in the program.

I thought it would be as simple as overriding the inspect method on
content, but that doesn't do the trick.

I've been through the internals of Test::Unit::Assertion, and it seems
to frustrate this effort.

cjs
 
C

Curt Sampson

I thought it would be as simple as overriding the inspect method on
content, but that doesn't do the trick.

Never mind, this does actually work if I set it in a different place.
There's some weird thing happening between defining inspect on an object
inside or outside a block to which a custom assert method yields, but I
can't be bothered to debug it.

cjs
 
R

rking

I know you said, "Nevermind," but I wanted to add this bit:

Don't forget about the third parameter to the assert messages. It is
very useful for either giving hints about the meaning of the
assertion, or to diagnose what went wrong, either of which can be
helpful for posterity.

It's important to know that assert_match(pat,obj) essentially matches
`obj.to_s =~ pat`. The output gives the impression that it's matching
`obj.inspect =~ pat`, but that's just sort of an artifact of
AssertionMessage#convert.

Here's some code/output:

require 'test/unit'
class Sampson
def initialize
@riddle = '"Out of the eater, something to eat;' +
'out of the strong, something sweet."'
end
class PhilistineTest < Test::Unit::TestCase
def test_quiz
nazirite = Sampson.new
pat = %r/eater/
assert_match(pat, nazirite, "#{nazirite} !~ /#{pat}/")
end
end
end

Loaded suite /home/rking/src/scrap
Started
F
Finished in 0.047188 seconds.

1) Failure:
test_quiz(Sampson::philistineTest) [/home/rking/src/scrap.rb:36]:
#<Sampson:0xb7ca2c74> !~ /(?-mix:eater)/.
<#<Sampson:0xb7ca2c74
@riddle=
"\"Out of the eater, something to eat;out of the strong, something
sweet.\"">> expected to be =~
</eater/>.

1 tests, 1 assertions, 1 failures, 0 errors

See that line immediately after the test_quiz(...) line? That's my
custom-provided line. It's kind of buried, but having it is at least
clearer than the lines below, which are a little misleading.

HTH,
-rking
 
P

Phlip

rking said:
assert_match(pat, nazirite, "#{nazirite} !~ /#{pat}/")
See that line immediately after the test_quiz(...) line? That's my
custom-provided line. It's kind of buried, but having it is at least
clearer than the lines below, which are a little misleading.

That's why I wrote assert_raise_message:

http://tinyurl.com/23tlu5

When inventing a new assertion - maybe an arbitrarily complex one - you
can't leave its user with "nil should not be nil". You should reflect
anything you know into the diagnostic. All assertions should take a
'message' field, for the user to add to the explanation.

When a test fails, maximizing the information output helps the user rapidly
decide whether to debug the failure, or just revert the code.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top