Make public the satisfyAnyOf and satisfyAllOf matchers that take arrays of matchers #861
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ys of submatchers This will make it easier/possible to matchers that wrap satisfyAnyOf and satisfyAllOf
|
+1 for this change, since Swift currently doesn't support splatting exposing both APIs seems like the best workaround. @ikesyo what are your thoughts 8000 on this? |
ikesyo
reviewed
Apr 24, 2021
Co-authored-by: IKEDA Sho <suicaicoca@gmail.com>
Co-authored-by: IKEDA Sho <suicaicoca@gmail.com>
|
@ikesyo Thanks for the review, done! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This will make it easier/possible to matchers that wrap
satisfyAnyOfandsatisfyAllOf.Rationale of PR
In one of my projects, I have the pattern of the
FakeCall<T>to test if callbacks were called and what the calls are. (gist of implementation from it, for reference. The relevant part isbeCalled<T>(_ expectations: [FakeCallPredicate<T>]) -> Predicate<FakeCall<T>>). One of the matchers essentially takes an array of(KeyPath, Predicate)s and processes them to just an array of Predicates before passing them off to a copy-paste-edit ofsatisfyAllOf.After the second time where I used a similar pattern (wrapping an array of predicates), I started to really wish that
satisfyAllOfwould be public, to better support this. I'm probably not the only one with this kind of idea, so I figure it would help others with this implementation.I don't have a similar use-case for
satisfyAnyOf, but it seemed like a good idea to givesatisfyAnyOfthe same treatment.The PR should summarize what was changed and why. Here are some questions to
help you if you're not sure:
What behavior was changed?
What code was refactored / updated to support this change?
What issues are related to this PR? Or why was this change introduced?
Is this a new feature (Requires minor version bump)?