Problem z milisekundami z Instant w jsonie podczas testów

Mam taki problem, że ilość milisekund (używam Instant) w oczekiwanej wartości (data utworzenia użytkownika) jest większa niż w aktualnej w teście.

Expected:[{"username":"user1","password":"$2a$10$sY6Du4nK6vU04ymkBTIT0Oto9Ckp1nnhonwc.XL7HtIqYhglPLCFO","role":"COMMON","status":"OPEN","creationDate":"2022-05-14T16:19:01.253102500Z"}]
Actual:[{"username":"user1","password":"$2a$10$sY6Du4nK6vU04ymkBTIT0Oto9Ckp1nnhonwc.XL7HtIqYhglPLCFO","role":"COMMON","status":"OPEN","creationDate":"2022-05-14T16:19:01.253103Z"}]

@Test
@WithMockUser(username = "MainAdmin", authorities = "ADMIN")
void return_users_and_200() throws Exception {
// given
var addedSampleUser= addSampleUser();
// when
var resultActions = mockMvc.perform(get("/users"));
// then
resultActions
  .andExpect(content().string(objectMapper().writeValueAsString(List.of(addedSampleUser))))
  .andExpect(status().isOk());
}

Tak naprawdę nie jest większa, tylko zaokrąglona - używasz różnych konwerterów w kodzie produkcyjnym i teście.

Charles_Ray napisał(a):

Tak naprawdę nie jest większa, tylko zaokrąglona - używasz różnych konwerterów w kodzie produkcyjnym i teście.

Tak, masz rację. W kodzie produkcyjnym to po prostu Spring sobie to konwertuje a w testach używam ObjectMappera a powinienem użyć tej klasy co Spring, tylko nie bardzo mogę ją znaleźć. Szukam tutaj: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/converter/HttpMessageConverter.html

Najlepiej by było, gdybys odpuścił sobie serializacje do obiektu w tym teście i porównywał po prostu stringi.

To jest test integracyjny i warto sprawdzić jak wyglada zwrotka z perspektywy konsumenta/klienta. Nie wiesz, jaki konwerter będzie po drugiej stronie, w szczególności może być inny niż Twój, wiec test może przechodzić, a zwrotka nie spełniać założonego kontraktu.

UPDATE

Zapomniałem dodać, że używam bazy H2 w testach. W logach zauważyłem, że baza przycina te milisekundy. Jeśli użyje jakiegoś in memory repo opertego na hash mapie to testy przechodzą normalnie, ale to chyba po prostu dlatego, że jest mniejsze opóźnienie. Pokombinuje z tym clockiem.

Wątek zainteresował mnie problemem podstawowym ... już chciałem się odezwać, że "no tak, floaty tak mają", ale wrzuciłem w goglarkę

The range of an instant requires the storage of a number larger than a long. To achieve this, the class stores a long representing epoch-seconds and an int representing nanosecond-of-second, which will always be between 0 and 999,999,999. The epoch-seconds are measured from the standard Java epoch of 1970-01-01T0000Z where instants after the epoch have positive values, and earlier instants have negative values. For both the epoch-second and nanosecond parts, a larger value is always later on the time-line than a smaller value.

Czyli nie jest to to float / double ze wszystkimi mankamentami reprezentacji i zaokrągleń, a już bardziej podobne do UUID, jeśli już do czegoś porównywać.
I myślę, że jako takie, nie powinno być zaokrąglane np podczas serializacji - ale to pewnie słabość genetyczna JSONa z genami Javascriptu - a reprezentowane dokładnie.