-
Notifications
You must be signed in to change notification settings - Fork 756
Better failure messages for Subset and Superset constraints #3505
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
Better failure messages for Subset and Superset constraints #3505
Conversation
6087bad to
951c0f5
Compare
| /// <param name="start">The starting point of the elements to write</param> | ||
| /// <param name="max">The maximum number of elements to write</param> | ||
| public static string FormatCollection(IEnumerable collection, long start, int max) | ||
| public static string FormatCollection(IEnumerable collection, long start = 0, int max = DefaultMaxItems) |
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.
Decided to add default values, since it is used in most cases with those arguments.
Let me know if there are any objections.
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.
Personally, I really like this. It makes it easy to ensure future calls to this will always respect the defaults unless the author explicitly decides not to.
Is there any way you could expose just this change in a separate commit on your branch? I'd like to graft it onto my own branch for #3502 to help simplify things there
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.
Updated PR to have separate commit for MsgUtils change. Still, not sure it's worth reusing it until this change is approved.
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 really like this change! Can I suggest updating all the places this method is currently used to make use of it too? The vast majority are currently passing in zero and ten.
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.
Done!
951c0f5 to
1f70da3
Compare
ChrisMaddock
left a comment
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.
What a great little quality-of-life improvement! Nice job adding this, @Dreamescaper!
Left a couple of minor suggestions - this will also need a review from another team member before merging.
| /// <param name="start">The starting point of the elements to write</param> | ||
| /// <param name="max">The maximum number of elements to write</param> | ||
| public static string FormatCollection(IEnumerable collection, long start, int max) | ||
| public static string FormatCollection(IEnumerable collection, long start = 0, int max = DefaultMaxItems) |
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 really like this change! Can I suggest updating all the places this method is currently used to make use of it too? The vast majority are currently passing in zero and ten.
| tally.TryRemove(_expected); | ||
|
|
||
| return tally.Result.ExtraItems.Count == 0; | ||
| _missingItems = tally.Result.ExtraItems; |
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.
Is this correct? It's a little confusing to read...maybe worth a comment? 🙂
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.
The reason is that we have
CollectionTally tally = Tally(actual);
tally.TryRemove(_expected);
in this file, whereas we have
CollectionTally tally = Tally(_expected);
tally.TryRemove(actual);
in CollectionSubsetConstraint.cs. I'm a bit tired, so I cannot determine if we can use MissingItems here and then just swap arund _expected and actual (I'm mostly worried about duplicates).
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.
The reason is that we have
CollectionTally tally = Tally(actual);
tally.TryRemove(_expected);
in this file, whereas we have
CollectionTally tally = Tally(_expected);
tally.TryRemove(actual);
in CollectionSubsetConstraint.cs. I'm a bit tired, so I cannot determine if we can use MissingItems here and then just swap arund _expected and actual (I'm mostly worried about duplicates).
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.
Added comment.
@mikkelbu
Seems like no issues with duplicates, but it affect order of parameters custom comparer lambda - .Using<int, string>((i, s) => ..) VS .Using<string, int>((s, i) => ..).
Currently this order differs between CollectionSupersetConstraint and CollectionSubsetConstraint.
While this looks like a bug, and would make sense to make it consistent, that would be a breaking change, so I'm not sure what would be better here.
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.
If it will be a breaking change, then I think the current solution - with the comment - is the right one 👍
mikkelbu
left a comment
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.
Also looks good from me with one comment. My main worry has nothing to do with this change, but that we are using the word set to describe something that can contain duplicates which a set cannot have by its definition, so rather we are talking about multisets or bags here 😄.
| tally.TryRemove(_expected); | ||
|
|
||
| return tally.Result.ExtraItems.Count == 0; | ||
| _missingItems = tally.Result.ExtraItems; |
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.
The reason is that we have
CollectionTally tally = Tally(actual);
tally.TryRemove(_expected);
in this file, whereas we have
CollectionTally tally = Tally(_expected);
tally.TryRemove(actual);
in CollectionSubsetConstraint.cs. I'm a bit tired, so I cannot determine if we can use MissingItems here and then just swap arund _expected and actual (I'm mostly worried about duplicates).
|
@mikkelbu Regarding your concern about use of the word "set"... Much of this comes from our early implementation of So it never had any reference to "sets" in the mathematical sense. Using "subset" and "superset" in this way is pretty common in normal language as well. |
mikkelbu
left a comment
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.
LGTM
ChrisMaddock
left a comment
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.
Nice - thanks for doing this @Dreamescaper!
Provide extra/missing items to
CollectionSubsetConstraintandCollectionSupersetConstraintfailure messages.E.g.