-
Notifications
You must be signed in to change notification settings - Fork 736
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
Bug in CollectionAssert.AreEqual for ValueTuples. #2518
Comments
Thanks for the simple repro @jam40jeff. A PR would be welcome, if you'd be willing. |
Sure, I would be willing to do that, but I may not be able to get to it for
a few days.
…On Mon, Oct 30, 2017 at 12:12 PM Chris Maddock ***@***.***> wrote:
Thanks for the simple repro @jam40jeff <https://github.com/jam40jeff>. A
PR would be welcome, if you'd be willing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2518 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbTOOJs2Gh37yJP5N1iHnVVOVuoUyBBks5sxfVcgaJpZM4QLVN0>
.
|
Great! No problem. 😄 |
I think this may be related to #2271. @jam40jeff Try doing it using Assert.AreEqual(l1, l2);
Assert.That(l2, Is.EqualTo(l1)); A side problem, which this issue should deal with, is that CollectionAssert should really not accept non-collections without giving an error. |
@CharliePoole What do you mean about I tried using lists (
|
But In So we need to make the logic for determining whether the type is a ValueTuple more strict. |
@jam40jeff AH! Never mind, I misread your example. Of course it's an array of ValueTuples, not just a ValueTuple. @mikkelbu Looks like you're on the right track. I haven't looked at the code, but I would expect that ValueTupleComparer should be called for each array element, not for the entire array. How come it's dealing with the array type rather than the member type? |
@mikkelbu It looks like the list of comparers ( Interestingly, the problem also happens with |
@jam40jeff Prior there was no special handling of tuples. This was introduced (by me :( ) in #893. I'll take a look at the PR. |
Yes, I noticed this looking at the history. Thanks for adding the Tuple
support. I simply refactored the Tuple/ValueTuple type detection code into
TypeHelper (it was in a couple places prior), then added a simple check to
see if we have an array type before running the rest of your logic.
…On Tue, Oct 31, 2017, 3:59 AM Mikkel Nylander Bundgaard < ***@***.***> wrote:
@jam40jeff <https://github.com/jam40jeff> Prior there was no special
handling of tuples. This was introduced (by me :( ) in #893
<#893>. I'll take a look at the PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2518 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbTOIsiINx3QotSVKr0bUNclcy3jum6ks5sxtNQgaJpZM4QLVN0>
.
|
@rprouse Is this issue slated to be released in 3.10? (https://github.com/nunit/nunit/milestone/34) |
@timotei yes, this will be released with 3.10. I was planning on doing the release this week, but I need to check with the @nunit/framework-team to ensure that there are no high priority issues blocking the release and I need to review the backlog. |
@timotei it is. I've just added the milestone. |
@mikkelbu feel free to add the milestone when merging pull requests. It makes it easier for me come release. I go through all closed issues before release and make sure that everything has the correct milestone assigned, so it is okay if you forget to add the milestone on merge. When a release goes out, all closed issues must have a milestone assigned. That is why I have the Closed without Action milestone. It allows me to only look at recently closed issues. |
Within a test, the following code works:
However, the following code crashes when running the test:
Here is the exception message and stack trace:
The text was updated successfully, but these errors were encountered: