断言JMockit期望结果与构造的实例相同

Question

这是现实生活中被精减的方法...真正的方法还可以做其他事情，但是我将一些奇怪的行为缩小为仅几行。 考虑一种尝试从java.util.Date ...创建java.sql.Timestamp的方法（不要介意我在此方法中做错了什么；这不是重点）：

public class MyTest {

    public Timestamp convertDateToTimestamp(Date d) {
        long l = d.getTime();
        Timestamp ts = new Timestamp(l);
        return ts;
    }

}

因此，我为此方法编写了以下JMockit JUnit测试用例：

@RunWith(JMockit.class)
public class MyTestTest {

    @Tested MyTest test;

    @Test
    public void testConvertDateToTimestamp(@Mocked final Timestamp ts, @Mocked final Date d) throws Exception {
        new Expectations() {
            {
                d.getTime(); result = 8675309l;
                new Timestamp(8675309l); result = ts;
            }
        };

         Timestamp retval = test.convertDateToTimestamp(d);
         assertThat(retval, sameInstance(ts));
    }

}

请注意最后一行中的断言...我想我应该确定自己正在获取与构造函数创建的实例完全相同的实例。

该测试返回一个非常特殊的结果：

java.lang.AssertionError: 
Expected: sameInstance(<java.sql.Timestamp@6e3c1e69>)
     but: was <java.sql.Timestamp@6e3c1e69>
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
    at com.example.dcohl.MyTestTest.testConvertDateToTimestamp(MyTestTest.java:32)
...

有人可以解释吗？ 我的断言失败了，因为它期待一个Timestamp实例，但是却得到了……那个完全相同的Timestamp实例？

现在，如果我检查是否相等，则使用is(ts)而不是sameInstance(ts) ，我的测试成功了。 成为同一对象并不重要； 平等就足够了。 但这是一个令人头疼的结果...

Answer 1

当测试记录构造函数期望值时，例如new Timestamp(8675309l); result = ts; new Timestamp(8675309l); result = ts; ，这仅意味着通过匹配的构造函数调用创建的将来的Timestamp实例在逻辑上将等同于ts模拟实例（即，它们将具有与ts上记录/验证的模拟行为相同的模拟行为）。 这并不意味着它们将是同一实例。 它们仍将是新实例。