-
-
Notifications
You must be signed in to change notification settings - Fork 769
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
Add docs for new array matchers #1210
Add docs for new array matchers #1210
Conversation
@@ -112,6 +112,26 @@ Requires the value to be a `Function`. | |||
Requires the value to be an `Array`. | |||
|
|||
|
|||
#### `sinon.match.array.deepEquals(iterable)` | |||
|
|||
Requires an iterable value to be deep equal another one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once you see it written down, this is weird. You're checking inalterable from the array matcher. I would expect the array namespace to contain array matchers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fearphage I agree, I also raised the same question in a comment at my PR at #1208.
However, I was just thinking if we should act upon those iterables as if they were arrays, after all this matcher has the word array in it.
Since we're calling methods from Array.prototype
and passing a value to be used as this
it would work if users had their own array implementations or with things like arguments
.
I can change this if you want me too, I'd like to do whatever you prefer. If we want to be more strict it would be good to accept Arrays
only, but if we want to allow other similar implementations this is the way to go.
Maybe we could also have an match.iterable
or something like that.
What do you think it's better? Let me know and we can fix this if needed 😄
Also, sorry for not having raised that question more actively before. 😓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the benefits and usage. I'm just saying when you document it, it looks weird/out of place. I would expect an array matcher to throw/error if I didn't pass it an array honestly. I was considering an iterable
matcher. I'd wait to see what other think about it though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fearphage Yes, a new iterable
matcher would be the most adequate option IMO.
Thanks for your input, I totally agree with everything you said.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing array to iterable is fine with me, as long as we do it now, before a new release.
But do we have a definition of iterable? Objects are iterable in a sense too (for ... in
) ... Is it anything that has a length property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expanding the namespace through match.map., match.set., etc
This is going to be a lot of duplicate or (hopefully) resused code, but I think that is the most explicit option.
Agree/disagree, @fearphage?
So the first option being to make this only work for arrays since it's in the array
namespace? If that is the case, I would agree. I think we should confirm that though.
For instance, matcher.array.startsWith(...)
should throw when you don't pass an array to it. It seems like you're doing 2 things at once here. matcher.array()
&& array.startsWith()
. So if I pass {length: 1, 0: 'foo'}
, it would fail saying the test expected an array. Are we in agreement or did I miss the mark?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So no duck typing then? Strictly Array.isArray()
? I am not super sure what it really brings to the table, since it would leave out arguments
and other array-like objects, but people can always convert these to proper arrays if need be, so it should be ok.
And since the test is for an array, I guess it should break on non-arrays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fatso83 @fearphage I totally agree with that. People using this matcher should be aware it will work for Array
objects only and anything else should be converted to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, seems all are pro. Care to update the docs, Lucas? As long as you don't change the interface you document you can also add any strengthening assertions you like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course!
I'm already working on the Map
and Set
matchers, for now I'll make sure to add commits allowing arrays only on the matchers we already have and update the docs. 😄
Btw, the docs have been put in the wrong folder. |
009fe53
to
d794443
Compare
d794443
to
739e4b0
Compare
739e4b0
to
a100d08
Compare
Here it is 😄 I have already started working on matchers for the PS.: Sorry for the coveralls spam, I was making sure the commit log was clean and so it ended up doing many builds. |
f9cacca
to
a8064c0
Compare
a8064c0
to
cd1e396
Compare
Great work. Thanks for the collaboration :-) |
Purpose (TL;DR)
This aims to add docs for each one of the changes made at #1208 (which adds new Array Matchers).
Solution
I've read the
CONTRIBUTING.md
file in thedocs
folder and I think this is the correct place to add the new docs, but I'm not 100% sure, so please correct me if I'm wrong and I'll add these pieces of information to the right place.Also, I'm not a native english speaker so please let me know if you find any spelling/grammar mistakes. It would be much appreciated 😄
PS: I've made this in a single commit, but I can split it up into multiple commits, one for each matcher, if you find it to be better.
How to verify
cd docs
on Sinon's root foldergem install bundler
bundle install
bundle exec jekyll serve
http://localhost:4000/releases/v2.0.0-pre.4/matchers/
and check the new docs