Dictionary assertions do not always use the dictionary's comparer #1233
Conversation
…parer of the dictionary
…the dictionary and not using Object.Equals(object)
|
Looks good! |
| } | ||
|
|
||
| IEnumerable<TKey> foundKeys = unexpectedKeys.Intersect(Subject.Keys); | ||
| IEnumerable<TKey> foundKeys = unexpected.Where(key => Subject.ContainsKey(key)); |
There was a problem hiding this comment.
Does this "bug" also affect the other methods in this class?
|
@rubenrorije are you still around? |
|
Sorry, I had other priorities so did not have time/mental bandwith to look at this earlier. I updated the xml documentation to reflect the code better. As far as I can see the only other method that does not use the keycomparer of the dictionary is the |
jnyrup
left a comment
There was a problem hiding this comment.
I'm fine with leaving Equal untouched.
|
One more thing. Could you also add a row to the https://github.com/fluentassertions/fluentassertions/blob/develop/docs/_pages/releases.md#600? |
See #1232.
I noticed in the source code that
GenericDictionaryAssertionsuses intersect to compare the keys from the dictionary and the unexpected keys, which does not use the equality comparer of the dictionary. The dual ContainKeys implementation as well as the other methods all use the ContainsKey on the dictionary which is correct.To illustrate the issue I added two unit tests and changed the implementation in the pull request.
I also updated the xml documentation of all
(Not)ContainKey(s)to reflect the code. The documentation was saying that the keys were compared using object.Equals which is not the case in the code.