“REFUTE To refute a proposition or theory is to establish or prove
that it is false. Lately many people have taken to using ‘refute’ as a
synonym for ‘deny’, 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’

“REFUTE To refute a proposition or theory is to establish or prove
that it is false. Lately many people have taken to using ‘refute’ as a
synonym for ‘deny’, 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.”

You wanna know what sucks? The basic problem here is ‘assert_no’ is
redundant,
so we should use one word. Let’s try to pick a word.

So try this:
length, because some language-lawyer wannabe on the interthing found a
“denigh”. Just my luck nobody used the internet back then…
That’s uglier than sin, but I like where you’re going with it. How
about “dessert?” Mmm…

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’

I think that’s why I have trouble with it…refute says to me we’re
disproving something. So we’d be proving something doesn’t work, proving
something fails, providing something otherwise expected to be true is
false. So I’d say that when an assertion fails, that failure
successfully refutes the condition being asserted. But refutation being
used as assertion seems wrong…we’re trying to show a positive result:
that some condition returns false or nil. We’re not trying to disprove a
condition, nor trying to prove a condition expected to be true is
actually false. refute implies to me that there’s a true expectation
we’re disproving, rather than an expected false/nil result we’re
trying to prove.

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.
I do not speak for everyone, but using closures just seems to be
right, it hides the data, avoids any possible clash and is very
elegant, but that is my personal view.
If you do not like closures it will be difficult to understand those
who like them, unless you undergo the trouble to work with closures
yourself and decide if it gives you an edge or not.
Furthermore I believe that using closures allows you to look a little
but farther than Ruby, which might be a good thing.

I like closures as much as
the next guy, but I don’t see how they revolutionize my testing life.
I would not think that this has anything to do with testing. All I
want to achieve is to minimize the risk that the user of a framework
stumbles into a debugging nightmare because she stepped on the feet of
the framework.

Oh that was a rant? I thought it was a very sensible question and I am
not cynical here at all.
Did I waste my time?

Aimed much less at you, and more at the 4-5 of these I’ve seen in the
past few days.
No offense taken … bones
R.

If you English native speakers cannot decide I will make this your
problem
I will rename #verify to#make_sure_it_behaves_almost_like_that_with_reasonable_certainty and#refute to#without_wanting_to_offend_anyones_philosophical_and_religious_feelings_i_guess_the_following_might_be_wrong
This will eliminate 99.999999% of name collisions too

Well I guess you understand what I mean, #refute really seems fine
because we are in a reduced context. As true as it might be that
refute does not prove the non existence of something in real life it
seems completely irrelevant in a boolean logic.
But maybe I should provide

#true? and #false?

BTW. I agree with Phlip, size does matter here, aligned code is just
easier to read.

Robert

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)