Identical setups are now not considered the same (regression) #295
Comments
…oped#295. There is still problematic code in the Interceptor for comparing the arguments of calls, but for now it no longer causes a problem with propeties with arguments as the expression string builder now reports the arguments for property reads. I've added a comment explaining the flaws (as I see them) in the Interceptor code in the hope that it will help when someone next as a problem, or at least stops them missing the same thing as I did earlier.
|
I finally got back to taking a look at this. The issue with comparing arguments by reference rather than by value has existed since long before my change, but my fix to make the comparison less buggy makes it more visible. Since I haven't got the time to come up with a solution to the GetHashCode and Equals implmentations, i've fixed the problem I was trying to fix in a different way (by making the string key include the arguments for properties). I've also added a comment to the problematic code in the Interceptor covering both the issue I found and the issue @cyanite found in the hope that it will help the next person to look at this code. To top it off I added a unit test for this issue. |
* Fixes #278. Only fixes some of the issue though. Also adds new VB test assembly, hopefully in a way people will be happy with * Another fix for issue #278 that no longer causes issue #295. There is still problematic code in the Interceptor for comparing the arguments of calls, but for now it no longer causes a problem with propeties with arguments as the expression string builder now reports the arguments for property reads. I've added a comment explaining the flaws (as I see them) in the Interceptor code in the hope that it will help when someone next as a problem, or at least stops them missing the same thing as I did earlier.
|
Please reopen if the mentioned commit/PR didn't fix the issue. |
The (partial) fix for #278 causes a regression in how identical setups are handled. Internally, a dictionary is used to prevent duplicates (and to let identical setups override eachother), but with the new equality code, this will almost never work. The reason is that each argument is compared by reference equality, from a
List<object>. Value types are boxed in order to be in this list, and will thus never be equal (consider that(object)1 != (object)1).The equality and hash code should be reworked. Ideally only the string in the key should be used, and #278 should be solved by adding the appropriate arguments to the key string.
We're forced to downgrade Moq due to this bug, and due to a bug in Castle.Core 3.3.3 (used by this Moq version) involving default parameters.
The text was updated successfully, but these errors were encountered: