상황
프로젝트에서 API를 개발하는 과정에서 통합테스트를 작성했고 로컬에서 테이트 코드가 성공적으로 동작하는것까지 확인했다. 이후 개발 내용을 깃허브에 Pull Request 를 날렸다. 분명 로컬에서는 전체 테스트가 성공적인걸 확인했지만 Github Actions CI과정에서는 실패했다..
@DisplayName("템플릿 식별자를 통해 템플릿을 상세조회한다.")
@Test
void getDetailTemplateTest() {
var user = UserFixtures.createUser();
var savedUser = userRepository.save(user);
var template = createTemplate(savedUser);
var savedTemplate = templateRepository.save(template);
var authContext = AuthFixture.createAuthContext(savedUser.getId());
var response = templateService.getDetailTemplate(authContext, savedTemplate.getId());
assertThat(response)
.extracting("id", "title", "questions","createdAt","updatedAt")
.containsExactly(savedTemplate.getId(),
savedTemplate.getTitle(),
savedTemplate.getContents(),
savedTemplate.getCreatedAt(),
savedTemplate.getUpdatedAt());
}
Github Actions
현재 프로젝트에서는 MySQL을 사용하고 있으며, `LocalDateTime`의 정밀도를 마이크로초(6자리)까지만 저장하도록 설정하였습니다. 그러나 CI 실패 로그를 확인하면, 테스트는 나노초(9자리)까지의 정밀도를 기대하고 있습니다. 반면, 실제로 저장되는 값은 마이크로초의 정밀도를 가지고 있습니다. 더욱이, 이 테스트는 로컬 환경에서는 성공적으로 실행됩니다.
이 차이의 원인은 운영체제별 `LocalDateTime.now()`의 동작 방식에 있습니다. 윈도우 환경에서는 2023-10-28T22:31:08.203047600과 같이 나노초(9자리)까지의 정밀도로 시간을 측정합니다. 반면, Mac 환경에서는 `2023-10-28T22:50:18.617465`처럼 마이크로초(6자리)까지만 측정됩니다. 이러한 차이에도 불구하고, 데이터베이스 설정에 따라 마이크로초까지만 저장됩니다. 그렇다면 9자리의 나노초 값은 어디에서 온 것일까요?
이는 LocalDateTime.now()를 호출하여 객체는 이미 9자리의 나노초 정밀도로 시간 정보가 할당되었기 때문입니다. 데이터베이스에 저장된 후에도, 객체의 시간 값은 자동으로 업데이트되지 않습니다. 따라서 초기에 설정된 9자리의 나노초 값이 그대로 유지되는 것입니다.
'BE > Java' 카테고리의 다른 글
Thread.run()과 start()의 차이 (1) | 2024.05.05 |
---|---|
[Java] List를 정렬하는 여러가지 방법 (2) | 2022.11.23 |
String vs StringBuffer vs StringBuilder (0) | 2022.11.07 |
[Java] 자바11의 간단한 설명 (2) | 2022.10.31 |
[Java] 객체 지향 설계 5원칙(SOILD) (0) | 2022.08.31 |