Question

这是一个从现实生活中被大肆渲染的方法......真正的方法做了其他事情，但我已经将一些奇怪的行为缩小到这几行。考虑一种尝试从java.sql.Timestamp创建java.util.Date的方法...（更别提我在这种方法中做错了什么;这不是重点）：

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;）时，它只表示通过匹配构造函数调用创建的未来Timestamp实例在逻辑上等同于ts模拟实例（即，它们将具有与ts上记录/验证相同的模拟行为。这并不意味着它们将是同一个实例;他们仍然是新的实例。

断言JMockit期望结果与构造

1 个答案: