'shouldNot' should handle nil subjects in some cases about kiwi HOT 10 CLOSED

If you are expecting myBar.foo to be nil, could you not use:

[myBar.foo shouldNotBeNil];

from kiwi.

If I were expecting it to be nil, you're right - I could do it that way. However, I'd like to make the weak assertion that it's not equal to baz - it can be nil or not nil. As long as it's not equal to baz, I'm happy.

from kiwi.

I haven't tested this so it might not work out of the box, but how about:

id foo = myBar.foo;
[[theObject(&foo) shouldNot] equal:bar];

from kiwi.

Another alternative is to use theReturnValueOfBlock:

[[theReturnValueOfBlock(^{ return myBar.foo; }) shouldNot] equal:bar];

from kiwi.

I could probably use one of your suggestions, but I like how clean Kiwi is and I'd like to be able to keep my specs clean. I can use one of these temporarily, but I'd really like to be able to keep my code as originally written in the issue.

from kiwi.

The problem with your example is it's simply not possible to send a message to nil; I can't think of a way around it other than boxing the variable.

from kiwi.

Good point. That brings up another question, then - how does [myBar.foo shouldNotBeNil]; work? If foo is nil, how can it fail? Or how does shouldBeNil work?

from kiwi.

shouldNotBeNil isn't a message, it is a macro that expands to a fragment that both sends a message, and creates an object that is an argument to the message.

Perhaps this is a simpler way to think about it:

[bobby shouldNotBeNil] expands to [bob shakeHandWith:[[alice alloc] init]]. shakeHandWith: would be implemented simply as "[visitor acknowledgeHandshakeBy:self]". If alice does not receive a handshake by the time the test ends, we know the message got sent to nil!

If you are familiar with the acyclic visitor pattern, this uses a similar mechanic, even though the intent doesn't really have anything to do with the pattern.

Hacky I know, but I felt that the end result made for easier reading.

from kiwi.

Wow - thanks for the explanation. So you're saying my request is impossible to implement, right? If that's the case, I have no problem with the issue being closed. :)

from kiwi.

Hmm, not impossible, but I would say the alternatives (not complaining about expectations on nil, or new keywords) are not compelling enough.

from kiwi.