Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature collections #90

Closed
wants to merge 5 commits into from

Conversation

paulsamuels
Copy link
Contributor

Add collection semantics

NSArray *array = @[ @1, @2, @1, @3 ];
expect(array).elements.to.equal(@1); //=> (1)=> expected: 1, got: 2, (3)=> expected: 1, got: 3

NSSet *set = [NSSet setWithArray:array];
expect(array).elements.to.equal(@1); //=> (element)=> expected: 1, got:2, (element)=> expected: 1, got: 3

Reduce complexity of applyMatcher:

ollieatkinson and others added 5 commits March 15, 2014 14:04
Fixed up code alignment in README.md
Any `EXPBlockDefinedMatcher` effectively ignores the argument passed to `matches:` and instead fetches the `actual` from it's instance with `self.actual`. This adds mental overhead and makes @ollieatkinson 's work on enabling a syntax similar to `expect(@[ @1, @2]).elements.to.equal(1)` for collections messy.
This method seems to add unnecessary complication to the calling convention and appears to only have originally existed to allow for Async testing. The `to:(NSObject **)actual` parameter in `-[EXPExpect applyMatcher:to:]` appears to only have existed for the purpose of being a flag to say “we have a value now” - this is no longer required with the fixes from the previous commit.
Some matchers like `EXPMatchers+notify` are currently using `failureMessageForTo` and `failureMessageForNotTo`
to signify the end of the expectation and perform any clean up such as unregistering for notifications.
This prevents the matcher from being reused. By adding an explicit cleanUpBlock the matcher can safely do
whatever clean up it needs to do and know that it is not going to be used again from that point.
  NSArray *array = @[ @1, @2, @1, @3 ];
  expect(array).elements.to.equal(@1); //=> (1)=> expected: 1, got: 2, (3)=> expected: 1, got: 3

  NSSet *set = [NSSet setWithArray:array];
  expect(array).elements.to.equal(@1); //=> (element)=> expected: 1, got:2, (element)=> expected: 1, got: 3

* Reduce complexity of `applyMatcher:`
@robb
Copy link
Member

robb commented Mar 31, 2014

How about adding explicit all an any semantics?

@paulsamuels
Copy link
Contributor Author

Could you provide an example?

You could easily add syntactic sugar for

expect(array).all.elements.to.equal(something);

I'm not so sure any would be as easy if this is what you where thinking?

@ahti
Copy link

ahti commented Mar 31, 2014

any would be very useful to have, imho. I could also imagine the variations one and none to be nice.

@paulsamuels
Copy link
Contributor Author

Here's an implementation that adds any paulsamuels@d9cf35f. I can't help but think this would be better implemented with something that takes the number of elements that should be required to pass as an argument, which would be fairly trivial to do off the back of the above commit

expect(collection).atLeast(5).elements.to.equal(2);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants