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

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

이전 포스팅에 이어 테스트 코드 유지보수를 이어나가 보겠습니다. 이전 포스팅에서 적용한 것들은 다음과 같습니다. test datasource 설정 (1) schema.sql, data.sql 추가 (1) 기획서를 참고하여 기존 로직 수정 (2) JPA 영속성 컨텍스트 관련 이슈 조치 (2) 이렇게 했을 때, 마지막 테스트 수행 결과는 다음과 같았습니다. 에러가 발생하는 테스트 케이스 여기서는 생각보다 다양한 Exception이 발생하고 있었습니다. 도메인 예외 케이스 ex. 필수값이 없거나, 적절하지 않은 상태 등.. DB로 부터 조회 결과가 없는 경우 repository.findById(id).get() 호출 시 반환된 Optional이 empty인 경우 데이터 insert 시 unique key 중복..

이전 포스팅에 이어 테스트 코드 유지보수를 이어나가 보겠습니다. 이전 포스팅에서 적용한 것들은 다음과 같습니다. test datasource 설정 schema.sql, data.sql 추가 이렇게 했을 때, 마지막 테스트 수행 결과는 다음과 같았습니다. 실패하는 테스트 케이스의 원인은 다음과 같았습니다. 테스트 예상 결과가 다른 경우 (expect ≠ result) 테스트 실행 중 에러가 발생한 경우 각 케이스 별로 살펴보겠습니다. 테스트 예상 결과가 다른 경우 기존에 작성했던 테스트 결과 대로 동작하지 않는 경우입니다. 해당 케이스들 중 첫번째는 특정 기능(ex. 알림)에 대한 테스트 케이스들이었습니다. 주문에 대한 알람 기능을 예로 들었을 때, 기존에 개발된 형상은 고객이 주문을 하면 고객도 알림을 ..

배경 저희 조직에서는 테스트 코드를 잘 작성하지 못하고 있었습니다. 저는 그러한 이유에는 크게 3가지가 있다고 생각했습니다. 시간 부족 테스트 코드 작성에 대한 이해 테스트 코드의 관리 상태 수 차례의 회고를 진행하며 팀원들에게 테스트 코드에 대한 중요성을 어필하였고, 관련 내용에 대해 별도로 논의를 거쳐왔습니다. 그 과정에서 3가지 중 시간 부족, 테스트 코드 작성에 대한 이해 항목은 어느 정도 해결할 수 있었습니다. 사실 마지막 항목인 테스트 코드의 관리 상태가 가장 어려운 문제였습니다. 테스트 코드는 결국 우리가 개발한 코드가 정상적으로 동작하는지 확인하는 용도가 가장 큰데, 기존에 존재하는 테스트 코드들이 환경이나 요구 사항 변동 등에 의해 정상적으로 동작하고 있지 않았습니다. 개인적으로 이 문제..

배경 저희 팀은 API, 화면 개발 모두 필요한 경우에는 BE(백엔드)와 FE(프론트엔드) 작업담당자가 REST API Request, Response 모델에 대해서 사전에 논의합니다. 논의한 내용을 바탕으로 각자 파트에서 작업을 진행하게 되죠. API 개발이 완료된 후에는 보통 DV 환경이 타 버전에 대한 검증으로 사용 중인 상황이 많기 때문에, 로컬에서 DV 환경에 DB를 바라보는 profile로 API 서버를 구동합니다. 이러한 환경에서 업무를 진행할 때, API 개발이 완료되어서 FE에 API 명세와 작업 브랜치를 전달하면 종종 문제가 발생합니다. API 에러 상황 Http status 5xx API 명세와 상이한 Request/Response 개발된 기능 외 기존 기능에 문제 발생 테스트 코드 ..