Expecting nil or false


#1

Hi,

I just ran into this issue. I have a method that returns: false, true,
nil or an object.

This method is used by another method to test for true/false. In Ruby
that’s easy to handle as nil and false evaluate to false, and everything
else evaluates to true, but RSpec seems to expect an exact value such as
nil, true, false, not_nil, etc.

Do I have to rewrite my return values to always return true or false?


#2

What about variable.nil? == true

Sent from Brian’s iPhone

On Mar 31, 2009, at 9:26 AM, “Fernando P.” removed_email_address@domain.invalid


#3

On Mar 31, 2009, at 12:08 PM, Fernando P. wrote:

nil, true, false, not_nil, etc.
Use the boolean matchers:

def foo?
nil
end

obj.should be_foo #=> fails
obj.should_not be_foo #=> passes

Scott


#4

On Tue, Mar 31, 2009 at 11:08 AM, Fernando P. removed_email_address@domain.invalid
wrote:

Do I have to rewrite my return values to always return true or false?
No, but you may have to use different matchers. What are you using?


#5

Do I have to rewrite my return values to always return true or false?
No, but you may have to use different matchers. What are you using?

I use: should be_false

Rspec complains it receives nil when it is expecting false.


#6

On Tue, Mar 31, 2009 at 12:11 PM, Fernando P. removed_email_address@domain.invalid
wrote:

Do I have to rewrite my return values to always return true or false?
No, but you may have to use different matchers. What are you using?

I use: should be_false

Rspec complains it receives nil when it is expecting false.

As would be expected.

What is the full expression? i.e. what is it that should be false (or
nil)?


#7

What is the full expression? i.e. what is it that should be false (or
nil)?

Basically:

def is_it_cool?
find(blabla, :conditions => ‘coolness > 1000’)
end

In order to stay consistent and as the question mark suggests that true
or false will be returned, I have updated my method too:

def is_it_cool?
!!find(…)
end

Is true that the dynamic aspect of Ruby allows us to not have to
statically type the return value of a method, so it could be an object,
nil or a boolean.

What do you think?


#8

Den 31. mars. 2009 kl. 18.34 skrev “Colfer, Brian”
removed_email_address@domain.invalid:

What about variable.nil? == true

No, that will not raise anything.

x.should == nil
Or
X.should be_nil
Ditto for false and true.

What have you been trying?

Aslak


#9

On Tue, Mar 31, 2009 at 12:54 PM, Fernando P. removed_email_address@domain.invalid
wrote:

or false will be returned, I have updated my method too:
What do you think?
I don’t know if you’re familiar with the concept of truthiness, but
that is what you’re talking about here. IMO, be_true should be
specific. I’m open to other opinions, and would consider changing the
way it works if we can do it without breaking everybody’s stuff.

Somebody joked about having a be_truthy matcher. Perhaps he actually
wrote one.

As for how I handle these things now, I would do this:

something.should be_cool

def cool?
!!find(…)
end

I find that almost every time I approach it this way, I land on a
predicate method that is ruby-ish. is_it_cool? is not ruby-ish. nor
would is_cool?

FWIW,
David