true! or false!

[Intransition]

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.

 

[Louis-Philippe]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Intransition]

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!"

 

[Brian Candler]

Thomas Sawyer 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.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

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.

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

 

[Intransition]

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

Could add the methods to NilClass too.

require 'test/unit'

class Object
=A0 def true! =A0 ; =A0self || raise("not true!") =A0 ; =A0end
=A0 def false! =A0; =A0self && raise("not false!") =A0; =A0end
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 TrueBangFalseBang < Test::Unit::TestCase
=A0 def test_object =A0 =A0 =A0 ; =A0[1,2,3][2].true! =A0 ; =A0end
=A0 def test_non_object =A0 ; =A0[1,2,3][3].false! =A0; =A0end
=A0 def test_true =A0 =A0 =A0 =A0 ; =A0(1=3D=3D1).true! =A0 =A0 =A0 ; =A0= end
=A0 def test_false =A0 =A0 =A0 =A0; =A0(1=3D=3D2).false! =A0 =A0 =A0; =A0= 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
=A0 include Test::Unit::Assertions
=A0 def true! =A0 ; =A0assert self =A0 ; =A0end
=A0 def false! =A0; =A0assert !self =A0; =A0end
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

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+=3D1
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.