Railsers:
My assert{ 2.0 } project will soon have its own package. It’s available
now as a
“technology preview”, bundled with assert_xpath.
It’s better than the classic test assertions because when it fails it
prints out
its complete expression, and the intermediate value of each of its
variables.
Install its dependency rubynode with it, like this:
gem install rubynode
piston import yar_wiki - Revision 475: /
vendor/plugins
The rest of assert_xpath (and its yar_wiki vehicle) are documented here:
http://assertxpath.rubyforge.org/
(Non-Rails uses can toss these two files into their library paths…
http://phlip.svnrepository.com/svn/yar_wiki/lib/assert_2_0.rb
http://phlip.svnrepository.com/svn/yar_wiki/lib/ruby_reflector.rb
…then include Assert2_0 into their test suites to use the library.)
assert{ 2.0 } is for any Test::Unit::TestCase, not just Rails; that’s
why I will
repackage it soon. Its source files are already portable; their only
dependencies are Ruby and rubynode.
To use it, simply replace any of your calls to assert, assert_equal,
assert_match, assert_kind_of, assert_operator, assert_not_nil, etc, in
your
developer tests. Replace them with assert{ raw ruby equivalent } (and
replace
assertions like assert_nil, assert_no_match, assert_not_equal with
assert{}'s
evil twin, deny{}).
You can write whatever you like inside - including sick complex
expressions -
so long as their last statement return a positive (or negative) value.
The classic assertions only exist for one reason - to print out their
values
when they fail. And then they don’t even reflect their variable names,
either.
When assert{} fails, it prints its complete expression, with each
intermediate term and its value, like this:
assert{ “a topic” == ( topics[“first”] ) } → false
topics → {“first”=>“wrong topic”}
topics[“first”] → “wrong topic”
The library is not published because I have not checked every single
Ruby
op_code off my list yet. (I had no idea there were so many!) If I’m
missing
one, you get a clean error message that RubyReflector does not have a
method
“_foo”, where “foo” is one of the opcode prefixes from Ruby’s internal
token
table. If that happens to you (simplify your assertion!), and report
“foo” to
me, so I can move it to the top of my do-list.
Warning: When the assertion succeeds, it only evaluates its expression
once. But
when it fails, it evaluates the expression several more times, to
extract the
intermediate values. This will defeat boolean short-circuiting, and will
hammer
any side-effects in your methods. As usual, sloppy testing requires
decoupled
code, but I can’t fix these without tweaking Ruby’s evaluation kernel!