[Ann] Verify, a very basic testing tool.

[Robert Dober]

Hi List

The Verify tool is a KISS verification and test tool, it is inspired
by Ara T. Howard's testy.rb.
Ara however has still implemented a BDD framework, the purpose of
Verify is to provide a Ruby Programmer
with a very simple yet effective tool to test her assumptions about code.

Verify was motivated by a reply to Ara's release post made by Phlip.
Phlip has made an excellent point about assert.
And that very often that is (almost?) all what is needed.
The Verify tool tries to implement exactly that idea and is the
simplest possible tool to do the job (for me).

Verify has the following goals

* Almost nothing to learn, one wrapper method and three test
methods with almost no parameters all save one
optional.
# At the end a resume of the verifications with an error message
for each failed verification
# will be printed to stderr or a mocking object.
# Strings and Arrays are fine for that purpose, as the reporter
uses #<< exclusively.


* No metaprogramming, no at_exit hook, execution of the
verification inside a wrapper object, no global namespace pollution,
except the Verify method.

* Wrapper behavior inference to the testee is limited to #verify,
#verify_not and #verify_exceptions.

* Very simple output

* "Last Line Says It All" feature "================" --> all tests
ok, "***************" --> not all tests ok.

USAGE EXAMPLES:

require 'verify'

Verify do
verify do 42 end
verify_not do nil end
verify_exceptions NameError do abcdefghijk end
end

Verify "that the universe is ok" do
verify "this only shows in error reports" do
1 / 0
end
end

LICENCE:
BSD

Enjoy
Robert

Ah yeah BTW if someone really wants to download this

http://rubyforge.org/frs/?group_id=3824&release_id=30476


--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Ryan Davis]

Verify do
verify do 42 end
verify_not do nil end
verify_exceptions NameError do abcdefghijk end
end

refute: same length as verify!
raises: ditto!
(assert: I like assert)

 

[Robert Dober]

refute: same length as verify!

Never heard of that word before, just checked it on Websters, thanx
Ryan great idea.

raises: ditto!
(assert: I like assert)

So do I, but assert is normally inserted into production code, and
Verify is still a testing tool, but you know it is so easy to alias
the methods in the anonymous module that creates the wrapper object in
the Verify method .
Cheers
Robert


--=20
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Robert Dober]

Thanks to Ryan I have changed #verify_not to #refute.
But not #alert and #raises because I am afraid that these method names
might shadow too much testee code .

Cheers
Robert

http://rubyforge.org/frs/?group_id=3824 (verify-0.1a)

 

[Robert Dober]

oops I forgot something important
Verify is Ruby1.9 only, do not look back .
R.

 

[Tom Cloyd]

oops I forgot something important
Verify is Ruby1.9 only, do not look back .
R.

Damn. I love this sudden burst of creativity around the topic of
testing. A Good Thing. Would love to try this new thing of yours.
Already successfully using Ara's.

But this 1.9 nonsense frustrates me. Much as I want to dive in (it's
installed and ready to go), I simply don't have time to move code I
depend upon into an environment where I don't know whether it will fly
or not, or whether it will splat after 3 days of investment and use. I
wish there was somewhere I could go to find out what gems run with 1.9
and what do not. But, that seems not to be the ruby way. That's plain
crazy, say I.

Maybe in a year it'll be different. Meanwhile, 1.87 works for me. Sad.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Phlip]

Damn. I love this sudden burst of creativity around the topic of
testing. A Good Thing.

Oookay. Here's a sneak preview of assert{ 2.0 } 0.4.8.

You know how Ajax works by generating JavaScript, and slinging it at your web
browser? And you know how Rails purportedly tests it with "assert_rjs"? Here's a
sample:

assert_rjs :replace_html, "advanced_filter", ""

Too cute, right?

Wrong! That expands to nothing but a big Regexp, like
/Element.update.*advanced_filter/. So a payload of "advanced_filter", or even a
subsequent Element.update('advanced_filter'), could fool it.

Further, at work we do a lot of in-house Ajax, so we are at liberty to render
entire partials at whim. We require our teeming minions to use only Firefox. But
all assert_rjs does with its third argument is drop it into assert_match. That
is not powerful enough to constrain our apps!

Just now while writing this post, I got Aaron Paterson's rKelly working in an
assert_rjs clone. rKelly uses racc to parse and evaluate JavaScript. This
matches our goal of _unit_ testing soft targets. Watir, Selenium, etc. are all
great, and they introduced a generation to testing in general. Buuuuuut they
work thru the browser. We are not inventing Ajax itself; we just need to
accurately spot-check that our own data go into the correct slots in our
JavaScript payloads.

So here's a test that simulates a Rails functional test with xhr :get :

@response = OpenStruct.newbody => "Element.update(\"label_7\", \"<input
checked=\\\"checked\\\" id=\\\"Top_Ranking\\\"
name=\\\"Top_Ranking\\\" type=\\\"checkbox\\\" value=\\\"Y\\\"
\\/>I want a pet &lt; than a chihuahua<input id=\\\"cross_sale_1\\\"
name=\\\"cross_sale_1\\\" type=\\\"hidden\\\" value=\\\"7\\\" \\/>\");")

assert_rjs :replace_html, :label_7

K, so far that looks like the original assert_rjs. But under the hood, it
actually lexed the Element.update() call:

ast.pointcut('Element.update()').matches.each do |updater|
updater.grep(RKelly::Nodes::ArgumentsNode).each do |thang|
div_id, html = thang.value

if target and html
div_id = eval(div_id.value)
html = eval(html.value)
if div_id == target.to_s
assert_match matcher, html

(Open question to Aaron - is that the best way to run the query?)

The test actually determines we really got hold of the Element.update('label_7',
....). No other JavaScript line will match.

Here's the assertions to match the text payload:

assert_rjs :replace_html, :label_7, /Top_Ranking/
assert_rjs :replace_html, :label_7, /pet &lt; than a chihuahua/

Ho hum; so far assert_rjs Classic could have done all that. But...

Because I have an exact string, not a rough match, I can now treat it as pure
HTML, and I can drop it into the mighty assert_xhtml()! Now the assertion looks
like this:

assert_rjs :replace_html, :label_7 do
input.Top_Ranking! :type => :checked, :value => :Y
input.cross_sale_1, :type => :hidden, :value => 7
end

From here, no matter how complex that rendered partial, the assertion can keep
up with it, and help make it safe to refactor and upgrade.

BTW Verify and Testy can get on board if they A> import Test::Unit::Assertions
(like certain other test rigs we could mention should), and B> implement
flunk(). Both of those are all a custom assertion should ever need...

 

[Robert Dober]

Robert Dober wrote:

But this 1.9 nonsense frustrates me. Much as I want to dive in (it's
installed and ready to go), I simply don't have time to move code I depend
upon into an environment where I don't know whether it will fly or not, or
whether it will splat after 3 days of investment and use. I wish there was
somewhere I could go to find out what gems run with 1.9 and what do not.
But, that seems not to be the ruby way. That's plain crazy, say I.

Maybe, indeed I had the very strong intention to write Lab419 to make
my code Ruby1.9 and 1.8 compatible. Too much work? Not enough time? I
dunno, finally I got tired of it and wanted my closure based Verify to
work. This goes without pain in 1.9.
But I agree with what you say.
<snip>
R.
--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

 

[Jens Wille]

hi tom!

Tom Cloyd [2009-04-04 01:14]:

I wish there was somewhere I could go to find out what gems run
with 1.9 and what do not.

there is: <http://isitruby19.com/>

cheers
jens

 

[Phlip]

Maybe, indeed I had the very strong intention to write Lab419 to make
my code Ruby1.9 and 1.8 compatible. Too much work? Not enough time? I
dunno, finally I got tired of it and wanted my closure based Verify to
work. This goes without pain in 1.9.
But I agree with what you say.

Here's a snip of my Rakefile, tuned for TDD:

task :default do
sh 'ruby186 test/assert2_rjs_suite.rb'
sh 'ruby187 test/assert2_rjs_suite.rb'
sh 'ruby190 test/assert2_rjs_suite.rb'
sh 'ruby191 test/assert2_rjs_suite.rb'

sh 'ruby186 test/rubynode_reflector_suite.rb'
sh 'ruby187 test/rubynode_reflector_suite.rb'
sh 'ruby190 test/ripper_reflector_suite.rb'
sh 'ruby191 test/ripper_reflector_suite.rb'

sh 'ruby186 test/assert2_suite.rb'
sh 'ruby187 test/assert2_suite.rb'
sh 'ruby190 test/assert2_suite.rb'
sh 'ruby191 test/assert2_suite.rb'
...

I'm implying that, after every couple of edits, I run every test in every Ruby.
This system works great to avoid the "Too much work? Not enough time?" quandary.

Actually, it doesn't. I lied. Most of those are commented out. I cannot figure
out how to get my peesashit Ubuntu to install all of those at the same time, and
I otherwise don't want to give up on the package manager. Debian's packaging for
Ruby sure sucks, huh?

 

[Robert Dober]

Robert Dober wrote:

Here's a snip of my Rakefile, tuned for TDD:

task :default do
=A0sh 'ruby186 test/assert2_rjs_suite.rb'
=A0sh 'ruby187 test/assert2_rjs_suite.rb'
=A0sh 'ruby190 test/assert2_rjs_suite.rb'
=A0sh 'ruby191 test/assert2_rjs_suite.rb'

=A0sh 'ruby186 test/rubynode_reflector_suite.rb'
=A0sh 'ruby187 test/rubynode_reflector_suite.rb'
=A0sh 'ruby190 test/ripper_reflector_suite.rb'
=A0sh 'ruby191 test/ripper_reflector_suite.rb'

=A0sh 'ruby186 test/assert2_suite.rb'
=A0sh 'ruby187 test/assert2_suite.rb'
=A0sh 'ruby190 test/assert2_suite.rb'
=A0sh 'ruby191 test/assert2_suite.rb'
=A0...

This is a very valuable and helpful thing, but you still got lots of
work to do for making these tests pass if you are a closure maniac
like me .
R.

 

[Phlip]

This is a very valuable and helpful thing, but you still got lots of
work to do for making these tests pass if you are a closure maniac
like me .

in theory, if it hurts, do it more often. If I wrote all those tests and code
_after_ setting up the Rakefile to hammer several Ruby versions, then I simply
don't notice the overhead. If something breaks I fix it or revert and try again.

You seem to think of adding the Ruby versions last...

 

[Tom Cloyd]

hi tom!

Tom Cloyd [2009-04-04 01:14]:

I wish there was somewhere I could go to find out what gems run
with 1.9 and what do not.

there is: <http://isitruby19.com/>

cheers
jens

Oh double flippin' damn! That's exactly what I had in mind. Ya just
gotta love this list. Ask and it shall be given, I may yet get religion.
Failing that...my pathetic code running wholly on Ruby 1.9, after which
I do lust.

Thank you Jens. You da man.

And thanks to all others for an entertaining thread (except Philip, that
"sneak preview of assert{ 2.0 } 0.4.8." stiff is so far beyond me it was
easily this week's personal low spot! However, knowing your intense
cleverness, I'm sure it is doing a number of far more rubyish souls a
ton of good. You're a major force in the universe, as I've long known.)

t.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jeremy McAnally]

Not to be contentious, but you use both define_method and *_eval to
generate code. Unless I don't know what that term means, I believe
you *do* use metaprogramming.

Though, I do have a question/concern/confusion/something. I
completely and utterly fail to see the point of these new closure
obsessed frameworks or tools. Nearly every bit of their functionality
could be wrapped up in a few simple helpers like this:

class Test::Unit::TestCase
alias old_assert assert

def assert(result =3D nil, &block)
result =3D block.call if block_given?
old_assert result
end
end

Unless I'm totally missing something? I realize it's a different
syntax or "DSL," and that's fine if that's your reasoning, but I don't
see how they're all that revolutionary. I like closures as much as
the next guy, but I don't see how they revolutionize my testing life.

</rant>

Aimed much less at you, and more at the 4-5 of these I've seen in the
past few days.

--Jeremy

Hi List

The Verify tool is a KISS verification and test tool, it is inspired
by Ara T. Howard's testy.rb.
=A0Ara however has still implemented a BDD framework, the purpose of
Verify is to provide a Ruby Programmer
=A0with a very simple yet effective tool to test her assumptions about co= de.

=A0Verify was motivated by a reply to Ara's release post made by Phlip.
Phlip has made an excellent point about assert.
=A0And that very often that is (almost?) all what is needed.
=A0The Verify tool tries to implement exactly that idea and is the
simplest possible tool to do the job (for me).

=A0Verify has the following goals

=A0 * Almost nothing to learn, one wrapper method and three test
methods with almost no parameters all save one
=A0 =A0 optional.
=A0 =A0 =A0# At the end a resume of the verifications with an error messa= ge
for each failed verification
=A0 =A0 =A0# will be printed to stderr or a mocking object.
=A0 =A0 =A0# Strings and Arrays are fine for that purpose, as the reporte= r
uses #<< exclusively.


=A0 * No metaprogramming, no at_exit hook, execution of the
verification inside a wrapper object, no global namespace pollution,
=A0 =A0 except the Verify method.

=A0 * Wrapper behavior inference to the testee is limited to #verify,
#verify_not and #verify_exceptions.

=A0 * Very simple output

=A0 * "Last Line Says It All" feature "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D" --> all tests
ok, "***************" --> not all tests ok.

USAGE EXAMPLES:

=A0 =A0 =A0 =A0require 'verify'

=A0 =A0 =A0 =A0Verify do
=A0 =A0 =A0 =A0 =A0verify do 42 end
=A0 =A0 =A0 =A0 =A0verify_not do nil end
=A0 =A0 =A0 =A0 =A0verify_exceptions NameError do abcdefghijk end
=A0 =A0 =A0 =A0end

=A0 =A0 =A0 =A0Verify "that the universe is ok" do
=A0 =A0 =A0 =A0 =A0verify "this only shows in error reports" do
=A0 =A0 =A0 =A0 =A0 =A01 / 0
=A0 =A0 =A0 =A0 =A0end
=A0 =A0 =A0 =A0end

LICENCE:
=A0 =A0 =A0 =A0BSD

Enjoy
Robert

Ah yeah BTW if someone really wants to download this

http://rubyforge.org/frs/?group_id=3D3824&release_id=3D30476


--
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

--=20
http://jeremymcanally.com/
http://entp.com/
http://omgbloglol.com

My books:
http://manning.com/mcanally/
http://humblelittlerubybook.com/ (FREE!)

 

[Ryan Davis]

I'm implying that, after every couple of edits, I run every test in
every Ruby. This system works great to avoid the "Too much work? Not
enough time?" quandary.

Actually, it doesn't. I lied. Most of those are commented out. I
cannot figure out how to get my peesashit Ubuntu to install all of
those at the same time, and I otherwise don't want to give up on the
package manager. Debian's packaging for Ruby sure sucks, huh?

sudo gem install ZenTest
multiruby_setup the_usual

task :default do
sh 'multiruby test/assert2_rjs_suite.rb'

sh 'multiruby test/rubynode_reflector_suite.rb'

sh 'multiruby test/assert2_suite.rb'
...

 

[Tom Cloyd]

hi tom!

Tom Cloyd [2009-04-04 01:14]:

I wish there was somewhere I could go to find out what gems run
with 1.9 and what do not.

there is: <http://isitruby19.com/>

cheers
jens

Oh double flippin' damn! That's exactly what I had in mind. Ya just
gotta love this list. Ask and it shall be given, I may yet get religion.
Failing that...my pathetic code running wholly on Ruby 1.9, after which
I do lust.

Thank you Jens. You da man.

And thanks to all others for an entertaining thread (except Philip, that
"sneak preview of assert{ 2.0 } 0.4.8." stiff is so far beyond me it was
easily this week's personal low spot! However, knowing your intense
cleverness, I'm sure it is doing a number of far more rubyish souls a
ton of good. You're a major force in the universe, as I've long known.)

t.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Phlip]

Though, I do have a question/concern/confusion/something. I
completely and utterly fail to see the point of these new closure
obsessed frameworks or tools.

Expensive setup is a design smell.

That said, sometimes your setups are expensive. Consider this outline:

describe 'frob_controller' do

setup do
@p_frobs = assemble_some_paid_up_frobs()
end

specify ... specify ... specify 'behaviors of paid-up frobs'

describe 'delinquent frobs'
setup do
@d_frobs = assemble_some_delinquent_frobs()
end

specify 'how paid-up and delinquent frobs interact' do
mess_with_both @p_frobs, @d_frobs
end
end

end

The first setup builds ideal frobs, and the specify blocks (elided) test them.

The second setup is nested, so its specifications run with both setups. The
nested specify blocks can use both kinds of frobs, together. You get this by
directly illustrating how the concepts nest. You don't need to write each setup
once and then somehow re-use it into various test suites.

A 'def test_frob' is a legacy of Java and its block-free programming styles. Yet
a test case is _not_ a method. You should not want to call it.

Treating blocks of testing code as objects makes weaving them together easier.
Contrast the "abstract test pattern", which Test::Unit::TestCase makes an
absolute pain in the 'nads. It's probably just as much fun in Java...

 

[Charles Oliver Nutter]

Never heard of that word before, just checked it on Websters, thanx
Ryan great idea.

I still contend that "refute" means to prove something is not true, not
to prove it false. refute do false end is meaningless.

- Charlie

 

[Charles Oliver Nutter]

Never heard of that word before, just checked it on Websters, thanx
Ryan great idea.

Drat, I didn't explain it well, and a quick check shows that refute is
"to disprove or to prove false", according to most dictionaries. I guess
I just don't like it as an opposite of "assert". All the thesauruses
I've checked list the antonyms of "assert" as "deny" and "reject", and
the antonyms of "refute" as "demonstrate", "prove", "accept", or
"embrace". There's a disconnect there I can't seem to remedy.

- Charlie

 

[Sean O'Halpin]

Drat, I didn't explain it well, and a quick check shows that refute is "t= o
disprove or to prove false", according to most dictionaries. I guess I ju= st
don't like it as an opposite of "assert". All the thesauruses I've checke= d
list the antonyms of "assert" as "deny" and "reject", and the antonyms of
"refute" as "demonstrate", "prove", "accept", or "embrace". There's a
disconnect there I can't seem to remedy.

- Charlie

I agree with you that 'refute' doesn't seem right. Not wanting to get
too pedantic about all this (but failing miserably , from
http://www.abdn.ac.uk/philosophy/guide/glossary.shtml:

"REFUTE To refute a proposition or theory is to establish or prove
that it is false. Lately many people have taken to using =91refute=92 as a
synonym for =91deny=92, but avoid this usage in philosophy. To deny that
God exists is not, in philosophical usage, to refute (or disprove) the
proposition that God exists."

Generally 'I assert P' means 'I am stating that proposition P is
true' and 'I deny Q' means 'I am stating that proposition Q' is false,
which would fit with your interpretation, i.e. if you deny Q and Q
turns out to be false, then you are correct. However, you haven't
proven anything. Your statement and reality just happen to be in
agreement. To refute Q is to ~prove~ that Q is false. There is no
further argument - Q is false and can only be false. I don't see how
we can assert that simply because a test turns out to return a false
value we have proven anything. We are simply getting assurance that
our assertions and reality are in agreement. In short, if we are
looking for a candidate to be the antonym of 'assert', 'deny' seems to
fit the bill.

A further wrinkle: 'prove' itself has the somewhat archaic meaning of
'test'... as in 'the exception that proves the rule'

Regards,
Sean