Phlip
1/29/2008 3:29:00 PM
I have invented a new concept of developer test assertions. This post is a
preview of its features, before I release it for Ruby. Porting it to other
languages is left as an exercise for the reader.
assert{ 2.0 }
I don't like the simple assertions - assert_equal, assert_match,
assert_not_nil, etc, in my developer tests. They only exist for
one reason - to print out their values when they fail. And then
they don't even reflect their variable names, either.
So I wrote an assertion to replace them. Put whatever you want
into it; it prints out your expression, and all its values.
Essentially like this:
x = 43
assert{ x == 42 } --> x == 42
x --> 43
deny{ x == 43 } --> x == 43 should not pass
x --> 43
The classic versions require more typing, and reflect less information:
assert_equal(x, 42) --> <43> expected but was \n<42>
assert_not_equal(x, 43) --> <43> expected to be != to \n<43>
This is a new concept of an assertion, and it simplifies the hell
out of developer tests. Before:
def test_attributes
topics = create_topics
assert_equal 'a topic', topics['first']
assert_not_nil topics['second']
end
After:
def test_attributes
topics = create_topics
assert{ 'a topic' == topics['first'] }
assert{ topics['second'] }
end
If the first assert_equal failed, it would only print out the two values.
When assert{} fails, it prints its complete expression, with each
intermediate term and its value:
assert{ "a topic" == ( topics["first"] ) } --> false
topics --> {"first"=>"wrong topic"}
topics["first"] --> "wrong topic"
And if the assert_not_nil failed, it would only reward us with
the infamous diagnostic "<nil> expected to not be nil". We would
prefer to see the expression that failed, and its intermediate
values!
assert{ topics["second"] } --> nil - should not pass
topics --> {"first"=>"wrong topic"}
topics["second"] --> nil
I'm still working on the library supporting this assertion.
It uses 'rubynode' to read your block's raw nodes. We already use
the assertion in all our projects at work, where it tends to
simplify the excess code we must write in test cases.