배경 이전 포스팅에 이어 테스트 코드 유지보수를 이어나가 보겠습니다. 이전 포스팅에서 적용한 것들은 다음과 같습니다. test datasource 설정 (1) schema.sql, data.sql 추가 (1) 기획서를 참고하여 기존 로직 수정 (2) JPA 영속성 컨텍스트 관련 이슈 조치 (2) Mock 기간 데이터 생성 메서드 수정 (3) TestExecutionListener 추가 (3) 이렇게 했을 때, 마지막 테스트 수행 결과는 다음과 같았습니다. 모두 해결이 된 것 같아 커밋 시 파이프라인에서 전체 테스트를 수행하도록 했습니다. 파이프라인에서 Maven 테스트를 실행하는 방법은 이전에 작성한 적이 있으니 여기서 참고 부탁드립니다. 테스트 파이프라인 구축 (Bitbucket, Teams 노티) 테..

배경 어느 날 사내 운영 환경 검증 중에 API 응답은 504 gateway timeout 이며, 어플리케이션 서버는 OOM(out of memory)이 발생하였습니다. org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded 원인은 무거운 API가 7,000 건 이상의 데이터를 처리하면서 발생한 상황이었습니다. 7,000 건 정도의 데이터가 많지 않다고 느껴질 수 있으나, 해당 API는 데이터 양이나 트래픽이 많아질 경우 충분히 이슈가 발생할 만한 상황이었습니다. 조회 API임에도 불구하고..

배경 오늘 함께 일하시는 FE 분께서 API 응답 데이터가 요구사항과 다르다고 확인을 부탁하셨습니다. 요구사항 자체는 간단했습니다. 주문 상태가 WAIT 인 데이터가 포함되면 안되었기에 해당 부분만 필터링을 추가하면 되는 작업이었습니다. 해당 기능에 대한 코드입니다. // Before public List getOrderModels(List markets, boolean urgent) { Map marketsById = markets.stream() .collect(Collectors.toMap(Market::getId, Function.identity())); List orders = getWaitingOrders(marketsById.keySet()); List OrderModels = Lists.n..

배경 간단한 API를 개발하는 작업을 진행하고 있었습니다. 해당 기능에 대한 도메인 모델(JPA 엔티티) 로직은 이미 작성되어 있는 상태라서 추가 작업이 많이 필요하지 않았습니다. 그래서 해당 모델 로직을 그대로 사용했고, 필요한 web 코드와 도메인 서비스 코드를 작성했습니다. 우선 개발 완료 후 Swagger 상으로 간단한 호출을 해봤는데 문제가 있었습니다. 이유는 도메인 JPA 엔티티 내부에 외부 의존성을 가지는 @Transient 필드가 존재했습니다. @Entity public class Order { .. @Transient @Inject @Getter(AccessLevel.NONE) private DomainEventListener domainEventListener; // is null @T..