Many modifications

[hartbit]

Improved the naming convention

Not becomes toNot
to is a new no-op
isGoing becomes will
isNotGoing becomes willNot

expect(var).equal(5);
expect(var).to.equal(5);
expect(var).toNot.equal(4);
expect(var).will.equal(5);
expect(var).willNot.equal(4);

Changed the contain matcher to work with any NSFastEnumeration class

Now, the contain matcher works with NSString and any class that conforms to the NSFastEnumeration protocol. Therefore, it works with NSSet, and with NSDictionary. Currently, it will only match key-value pairs with NSDictionary. Perhaps we need haveKey/haveValue matchers specifically for NSDictionary.

Fix ARC error with the beIdenticalTo matcher

With projects using ARC, the beIdenticalTo matcher caused an error if the expected value is of type id, as ARC does not allow implicitly casting from id to void*. I added a beIdenticalTo macro that explicitly does a bridge cast.

Fixed a false negative bug with negative asynchronous

When expecting an asynchronous negative, if the matchBlock returns true, we will return a fail before waiting the timeout. I modified the asynchronous tests to fail with that bug and fixed the bug by taking into account the negative in the asynchronous loop.

[petejkim]

Hey I am sorry. I don't know how I missed this. Changes look good, but is this backwards-compatible?

[petejkim]

If it isn't I might have to increment major version number and add some more features :P

[hartbit]

Changes look good, but is this backwards-compatible?

Unfortunately not. As I took the liberty of changing the naming convention heavily, I thought it was best not to leave two conventions in parallel. What do you think?

If it isn't I might have to increment major version number and add some more features :P

I'm also planning on adding a conformToProtocol matcher.

By the way, I spent a while trying to implement exception matching like so:

expect([object methodCall]).to.raise();
expect([object methodCall:nil]).to.raiseException(@"NSInvalidArgumentException");

But I got stuck for several reasons. First of all, the expect macro expects an expression that returns a value. Of course, that can be fixed by wrapping the calls in a block like this, but it's not very elegent:

expect(^{ [object methodCall] }).to.raise();
expect(^{ [object methodCall:nil] }).to.raiseException(@"NSInvalidArgumentException");

But I got another problem implementing the asynchronous matching:

expect(^{ [object methodCall] }).will.raise();

Indeed, I wrapped the calls to the run loop in a try/catch block, but it seems that exceptions that happened did not get caught by that try/catch block. Any ideas?