Allow #must_be and #wont_be to test truthiness / falsiness

[BMorearty]

I appreciate issue #31. Along those lines it would be nice to be able to test truthiness and falsiness without comparing a result to true or false.

Instead of this:

some_obj.truthy_method.must_equal true
some_obj.falsy_method.must_equal false

It would be nice to do this:

some_obj.truthy_method.must_be
some_obj.falsy_method.wont_be

I.e., use MiniTest::Spec to test Ruby's idiomatic Boolean logic where nil and false are falsy and everything else is truthy. I can already do this with MiniTest::Unit:

assert(some_obj.truthy_method)
refute(some_obj.falsy_method)

Note: at first I considered adding Object#truthy? and Object#falsy? methods and using must_be :truthy? etc. But I think the 0-arg must_be and wont_be methods are nicer in two ways: they don't add methods to Object and they are slightly more concise.

(And no, I didn't get this idea from RSpec. :-)

[zenspider]

I'd rather not overload must_be and wont_be any further. They're complex enough as it is. I'd recommend adding must_be_truthy and wont_be_truthy.

[BMorearty]

That sounds reasonable.

[zenspider]

Honestly, I still have misgivings about this issue. The number of plain assert calls that I have in non-rails apps is exactly zero. And the rails apps are rails' fault.

There just isn't much value in saying "this should not be one of two values out of the infinite range of values possible"... Instead, you should test that you actually know what it is. For all you know you get an array back when you think it should be a number... By testing just truthiness, you get very little value (or security) out of your tests.

[BMorearty]

I can understand that. The case where I find it useful to test truthiness is when a method's documentation states that its return value indicates whether some condition is true, without saying that it specifically returns true or false (i.e. a method whose code doesn't coerce the return value using !!). You said "Instead, you should test that you actually know what it is," but in the case I just mentioned you really don't know what it is--so you can't test against that.

That's the pragmatic argument, and the one that matters to me. The purist argument would be: there should be parity between the test API and the spec API.

[sunaku]

Did you know that require "minitest/spec" also pulls in require "minitest/unit"? What prevents you from using MiniTest::Unit's assert() and refute() methods in your specs? It couldn't be because of purity because MiniTest::Spec != RSpec and there's already a divergence in vocabulary ("must" vs. "should") anyway.

[zenspider]

@sunaku, that's a good point. Assert is available and really... I don't really see the added value of this. Esp if the justification is to test some other library's ill-defined response.

I think I'm going to bury this.

[rickhull]

What about just #must? File.exists?('/etc/passwd').must

Kind of weird, in a Louis CK way. But must and wont are sufficient for truthy/falsy. Just throwing it out there.