True! or false!

Ruby
1

Making good use of polymorphism I had this idea for assertion methods:

class TrueClass
# Assert true.
#
# (x == y).true!
#
def true!
true
end
# Assert false.
#
# (x == y).false!
#
def false!
raise “not false!”
end
end

class FalseClass
# Assert true.
#
# (x == y).true!
#
def true!
raise “not true!”
end
# Assert false.
#
# (x == y).false!
#
def false!
true
end
end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

2

I believe the more idiomatic way of doing it would be with question
marks,
isn’t it?

.true? instead of .true!

exclamation marks are usually for destructive methods, question marks
for
booleans.

2010/11/4 Intransition [email protected]

3

On Nov 4, 7:21am, Louis-Philippe [email protected] wrote:

I believe the more idiomatic way of doing it would be with question marks,
isn’t it?

.true? instead of .true!

exclamation marks are usually for destructive methods, question marks for
booleans.

Originally I did not have the exclamations at all, just .true, but
added them to give it some extra umph b/c it is raising an error.

A question mark would indicate that it returns either true or false.
For instance, Facets defines #true? and #false? to work like #nil?

An exclamation doesn’t necessarily mean destructive --that’s just it’s
most common use. The actual meaning is much more general, something
like “hey, this does something more than usual!”

4

On Thu, Nov 4, 2010 at 5:55 AM, Intransition [email protected]
wrote:

Assert false.

 true

end
end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

You would need to override at a higher level, I think, because I
frequently
use object/nil instead of true/false.

require ‘test/unit’

class Object
def true! ; self || raise(“not true!”) ; end
def false! ; self && raise(“not false!”) ; end
end

class TrueBangFalseBang < Test::Unit::TestCase
def test_object ; [1,2,3][2].true! ; end
def test_non_object ; [1,2,3][3].false! ; end
def test_true ; (1==1).true! ; end
def test_false ; (1==2).false! ; end
end

I like it, except that it doesn’t count these as assertions. Even if you
mix
the assertions module into object and use the assert methods, like this:

class Object
include Test::Unit::Assertions
def true! ; assert self ; end
def false! ; assert !self ; end
end

You would get results like “4 tests, 0 assertions, 2 failures”, maybe if
you
look even further under the hood you could figure out how to get them to
count. Or just choose to not care, but for me, that is a number I like
to
see :slight_smile:

5

On Nov 4, 1:31pm, Josh C. [email protected] wrote:

end

Assert true.

def false!
true
end
end

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

You would need to override at a higher level, I think, because I frequently
use object/nil instead of true/false.

Could add the methods to NilClass too.

require ‘test/unit’

class Object
def true! ; self || raise(“not true!”) ; end
def false! ; self && raise(“not false!”) ; end
end

Hmm… Yes, that might be better b/c then anything other then false
and nil will evaluate as true too. That is a good thing, right?

class Object
include Test::Unit::Assertions
def true! ; assert self ; end
def false! ; assert !self ; end
end

You would get results like “4 tests, 0 assertions, 2 failures”, maybe if you
look even further under the hood you could figure out how to get them to
count. Or just choose to not care, but for me, that is a number I like to
see :slight_smile:

Yes, that’s possible but it depends on which test framework you are
using. For MiniTest, for instance, it would probably be something
like:

MiniTest::Assertions._assertions+=1
raise MiniTest::Assertion.new(err)

Too bad there isn’t some sort of core support for this kind of thing
that could be used across test frameworks.

6

Thomas S. wrote in post #959291:

If only the error message could say something about WHAT was not true
or false, this could be pretty nifty.

You could override the exception message:

class TrueClass
def false!(err = “not false!”)
raise err
end
end

(1 == 2).false! “Maths is broken”

You end up with something like dfect, just with different ordering of
the values.