【问题标题】:Should one override equals method for asserting the object equality in a unit test?是否应该覆盖等于在单元测试中断言对象相等的方法?
【发布时间】:2010-11-13 21:10:32
【问题描述】:

假设我们通过断言结果对象的所有属性与预期结果对象的属性相等来测试方法的结果。我们是否应该实现 equals 方法并使用 Assert.AreEqual(expectedResult, actualResult)... 但是 equals 在生产代码中可能意味着不同的东西。

最佳做法是什么?

  • 通过重写的equals方法断言对象的相等性

  • 断言所有属性的相等性

【问题讨论】:

    标签: unit-testing equals assert assertions


    【解决方案1】:

    我只使用自定义断言。主要有两个原因:

    • 不要将测试问题强制投入生产。这意味着equals 在测试方法中的含义可能与生产代码中的含义不一致;
    • equals 对于所有测试来说可能不够好。不同的测试需要不同的断言,因此您最终可能会使用自定义断言。

    【讨论】:

    • 我认为您是对的,但是如果无法从测试内部访问被测对象的属性,该怎么办。使用反射?
    【解决方案2】:

    我认为这个问题与标准的做事方式没有任何关系。这是一个思考你的测试应该测试什么的问题。

    如果要测试所有属性是否相等,请断言所有属性是否相等。

    如果您想测试整个对象的 Equals 方法的返回值,请改为断言。

    【讨论】:

      【解决方案3】:

      如果您正在测试返回值对象(例如,货币值、元组或映射)的方法或函数的返回值,那么检查结果对象是否等于预期值是有意义的结果对象。在这种情况下,equals 的标准实现应该做你想做的。

      同时,如果您在某个对象上调用一个 mutator,然后检查它是否按预期改变了该对象,我认为只检查应该更改的对象的那些属性会更有意义。这可以防止您必须对 equals 进行自定义定义,这无论如何都会掩盖您期望在测试中发生的事情。

      【讨论】:

        猜你喜欢
        • 2014-06-25
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-07-22
        • 2016-01-22
        • 2011-11-22
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多