[英]Mockito Unit tests - Timestamps are different
Mockito 測試有一些問題。
我目前收到此錯誤:
Argument(s) are different! Wanted:
repository.save(
uk.co.withersoft.docservice.repositories.hibernate.MetaDataEntity@3e437e6c
);
-> at uk.co.withersoft.docservice.datastore.impl.MetaDataStoreImplTest.storeClaimMetadata(MetaDataStoreImplTest.java:55)
Actual invocation has different arguments:
repository.save(
uk.co.withersoft.docservice.repositories.hibernate.MetaDataEntity@3e361ee2
);
我很確定這是因為MetaDataEntity
中的時間不同
//這是我應該得到的
id = null
metaData = "{"caseReference":"CN00000001","claimReference":"LN00000001","rpsDocumentType":"REJ","documentTitle":"Claims LN00000001 (Claimant: Mr LOCAL HOST) REJ-Rejection letter"}"
batchId = 0
state = "Saved MetaData to DB"
lastUpdatedDate = {Timestamp@1517} "2018-07-25 18:39:21.993"
createdDate = {Timestamp@1518} "2018-07-25 18:39:21.993"
// 這實際上是我得到的。
id = null
metaData = "{"caseReference":"CN00000001","claimReference":"LN00000001","rpsDocumentType":"REJ","documentTitle":"Claims LN00000001 (Claimant: Mr LOCAL HOST) REJ-Rejection letter"}"
batchId = 0
state = "Saved MetaData to DB"
lastUpdatedDate = {Timestamp@1530} "2018-07-25 18:39:49.274"
createdDate = {Timestamp@1531} "2018-07-25 18:39:52.716"
這是我的測試用例:
@Test
public void storeClaimMetadata () throws JsonProcessingException {
ClaimMetaData metaData = constructMetaData();
MetaDataEntity mockResponseMetaDataEntity = new MetaDataEntity();
mockResponseMetaDataEntity.setId(1);
when(repository.save(any(MetaDataEntity.class))).thenReturn(mockResponseMetaDataEntity);
Integer result = testSubject.storeClaimMetadata(metaData);
assertEquals(Integer.valueOf(1), result);
final ObjectMapper mapper = new ObjectMapper();
String jsonMetaData = mapper.writeValueAsString(metaData);
MetaDataEntity expectedMetaDataEntity = new MetaDataEntity(null,
jsonMetaData,
0,
"Saved MetaData to DB",
new Timestamp(System.currentTimeMillis()),
new Timestamp(System.currentTimeMillis()));
Mockito.verify(repository, times(1)).save(expectedMetaDataEntity);
}
//Creates a ClaimRequest
private ClaimMetaData constructMetaData() {
final ClaimMetaData metaData = new ClaimMetaData("CN00000001",
"LN00000001",
"REJ",
"Claims LN00000001 (Claimant: Mr LOCAL HOST) REJ-Rejection letter");
return metaData;
}
任何幫助將非常感激。 這讓我發瘋了!!
這正是人們使用依賴注入的原因,因此他們可以指定返回可預測結果的測試合作者。 用對Timestamp.from(Instant.now(clock))
調用替換硬編碼的new Timestamp(System.currentTimeMillis)
內容。
java.time.Clock
是一個可用於獲取時間戳值的接口。 可以使用返回系統時鍾的工廠方法之一將真正的實現注入到正在測試的代碼中,如下所示(使用 Spring Java 配置):
@Bean
public Clock clock() {
return Clock.systemDefaultZone();
}
對於測試代碼,您可以有一個實現,您可以在其中指定希望時鍾返回的時間:
@Before
public void setUp() {
clock = Clock.fixed(date.toInstant(), ZoneId.of("America/NewYork"));
systemUnderTest.setClock(clock);
}
這是“按設計工作”。
您正在調用計算時間戳的服務。 像現在。
然后你有一個測試用例,它有一些設置正在進行,也獲取時間戳。 現在。
猜猜看:雖然上面的這兩個“現在”彼此接近,但它們之間仍然存在一些延遲。
要檢查是否相等,當時間標志完全相同只能工作! 但它們不是,因為它們一個接一個地創建,中間有非常明顯的延遲!
含義:您需要查看如何控制在應用程序中創建的時間戳,例如“時間戳應該是 t1 和 t2”。 這樣您的測試就可以檢查“我找到了 t1 和 t2”。
或者,您只需更改驗證步驟:您可以比較那些應該相等的部分,而不是嘗試使用“相等”的對象(因為時間戳不同,所以不能相等!),對於時間戳,您可以檢查它們是否“足夠接近”。
在 Code 中,您可以使用new Timestamp(DateTimeUtils.currentTimeMillis())
而不是使用new Timestamp(System.currentTimeMillis())
new Timestamp(DateTimeUtils.currentTimeMillis())
。 這里 DateTimeUtils 來自 jodatime。
在測試用例中,可以在下面使用。
private SimpleDateFormat DATE_FORMATTER = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss:SSS");
@Before
public void before() throws Exception {
// define a fixed date-time
Date fixedDateTime = DATE_FORMATTER.parse("01/07/2016 16:45:00:000");
DateTimeUtils.setCurrentMillisFixed(fixedDateTime.getTime());
}
@After
public void after() throws Exception {
// Make sure to cleanup afterwards
DateTimeUtils.setCurrentMillisSystem();
}````
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.