Improve handling of object-typed nil values during argument matching

[briancroom]

The existing tests around the usage of nil generally use a simple nil literal, which seems to be treated as type int by the compiler. I've fixed behavior and crashes around the usage of nil which is typed as id.

[idoru]

f20cdc2 is tricky. I can understand the motivation for the stubbed method argument to match, but this also impacts the equals matcher in test assertions (See #100) for some history. We may have to do some transformation of the nil argument passed to .with() instead.

[briancroom]

Hm I see. Could elaborate a bit on the motivation for reverting #100, perhaps with an example? I'd like to add some tests to specify the aspects of the equals matcher that we want to preserve before taking another go at this.

[jeffh]

The reason for reverting #100 is to not have to constantly check for nil when writing expectations. Say comparing this:

    Items.firstObject should equal(array.lastObject)

This expectation can pass in a case that can be more surprising since both can return nils. It's more common in tests to expect non-nil than nil values.
—
Sent from Mailbox for iPad

On Sat, Apr 19, 2014 at 5:28 PM, Brian Croom notifications@github.com
wrote:

Hm I see. Could elaborate a bit on the motivation for reverting #100, perhaps with an example? I'd like to add some tests to specify the aspects of the equals matcher that we want to preserve before taking another go at this.

Reply to this email directly or view it on GitHub:
#226 (comment)

[briancroom]

Got it. I've been doing some additional work on this, but I did have one question. Given the same context as above, should it pass or fail with the negative matcher?

items.firstObject should_not equal(array.lastObject)

I'm thinking it should fail based on the same reasoning, but that does not appear to be the current behavior.

[jeffh]

I'm thinking that it should, but that fix might introduce unintended regressions at this point. We'll need to discuss this more for that case.—
Sent from my iPhone

On Wed, Apr 23, 2014 at 8:45 AM, Brian Croom notifications@github.com
wrote:

Got it. I've been doing some additional work on this, but I did have one question. Given the same context as above, should it pass or fail with the negative matcher?
items.firstObject should_not equal(array.lastObject)

I'm thinking it should fail based on the same reasoning, but that does not appear to be the current behavior.

Reply to this email directly or view it on GitHub:
#226 (comment)

[briancroom]

I've pushed out some more work that corrects the behavior of compare_equal with nil, while allowing nil argument matches, as well as improving nil handling in several other places.

[idoru]

This behavior looks good now. I'm not sure the series of commits to arrive at this behavior should be on master, though. What do you think about squashing them?

[idoru]

Thanks for tidying up!