实现 IEquatable(T) 的两个对象的 Assert.Equals 不使用 equals 方法
我有一个实现 IEquatable(Type) 的自定义类型 Type。 然后我新建了该类型的两个实例,它们都不是 Null
Assert.IsTrue(obj1.equals(obj2)) //Success
Assert.AreEqual(obj1, obj2) //False
Assert.AreEqual(Type)(obj1, obj2) //False
第一个实例命中了我的 equals,第二个实例命中了 ToString() 有什么建议吗?
更新
一些代码来说明:http://pastebin.com/1uecrfeW
更多更新
如果我必须重写基本等于,即使有更好的(通用)等于可用,那么实现 IEquals(T) 有什么用呢?
I have a custom type Type that implement IEquatable(Type).
Then I new up two instances of the type, none of them are Null
Assert.IsTrue(obj1.equals(obj2)) //Success
Assert.AreEqual(obj1, obj2) //False
Assert.AreEqual(Type)(obj1, obj2) //False
The first one hits my equals, the second one hits the ToString()
Any suggestions?
update
some code to illustrate: http://pastebin.com/1uecrfeW
more update
If I have to override the base equals, even if a better (generic) equals is available, then what's the use of implementing IEquals(T)?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我的猜测是,它实际上击中了
Equals(object)
,而不是Equals(T)
。如果您没有覆盖Equals(object)
那么它可能会导致断言失败,然后断言会使用ToString
创建有用的失败消息。如果您可以展示一个简短但完整的程序来演示问题(包括您正在调用哪个
Assert
方法 - NUnit?还有其他东西吗?),那会有所帮助。My guess is that it's actually hitting
Equals(object)
instead ofEquals(T)
. If you haven't overriddenEquals(object)
then it's probably failing the assertion, which then usesToString
to create a useful failure message.If you could show a short but complete program which demonstrates the problem (including which
Assert
method you're calling - NUnit? Something else?) that would help.IIRC Assert.AreEqual 是非泛型的,因此仅 object.Equals 适用;尝试检查非泛型 object.Equals 的覆盖。
除了通过反射调用通用方法的不便之外,对象还可以实现多个
IEquatable
(针对不同的T)。因此,在我看来,非通用版本在这里是有意义的。IIRC Assert.AreEqual is non-generic, so only object.Equals applies; try checking the override of non-generic object.Equals.
In addition to the inconvenience of calling a generic method via reflection, the objects could also implement multiple
IEquatable<T>
(for different T). So the non-generic version makes sense here, IMO.