코딩공장공장장

DB 연동 테스트는 Repeatable하고 Independent한 테스트 환경을 유지하는 것이 중요하다.테스트를 여러번 실행해도 같은 결과가 보장되기 위해서 db의 상태가 변하지 않고 늘 일관되게 유지되야한다. 이번 포스팅에서 Flyway, TestContainer를 이용하여 일관되고 독립된 테스트 db를 구축하는 방법에 대해 소개하려고 한다. Flywayflyway는 DB 마이그레이션(변경사항)을 형상관리하는 소프트웨어이다.프로그래밍 코드를 형상관리하는 git과 같이 DB 마이그레이션 정보를 담은 sql 파일을 형상관리한다고 생각하면 된다. flyway는 주로 형상관리 목적으로 사용되지만 테스트 DB 환경 구축을 위해 사용될 수도 있다.반복 실행 가능한 R 파일을 통해 더미 데이터를 추가하여 DB 상태..

용어 정리 테스트 더블 : 실제 객체들 대신해서 테스팅에서 사용하는 모든 객체Dummy : 객체는 전달 되지만 사용되지 않는 객체Fake : 실제 동작은 하나 production과는 달리 단순화된 동작을 제공Stub : 미리 준비해둔 결과를 제공Spy : Stub의 역할을 하며 호출 내용에 대해 기록Mock : 호출 기록을 저장함, 주로 return type이 없는 더블에 많이 적용함 테스트 코드를 작성할 때, 테스트 대상이 아닌 의존 객체를 테스트 더블로 대체하여 사용하는 경우 모키토 프레임워크를 많이 이용한다.나 역시도 모키토 프레임워크를 이용하여 테스트 더블들을 조작하며 여러 시나리오에 대해 테스트를 했었다.허나, 모키토 프레임워크의 리플렉션 사용으로 인한 테스트 실행시간 부하, 스레드 언세이프로 ..

스프링 테스트의 경우 컨텍스트 로딩으로 많은 시간을 잡아 먹는다.잦은 컨텍스트 로딩은 테스트 코드 실행 시간을 많이 잡아먹는 주범이기도 한다.스프링은 각 테스트 케이스에서 사용하는 컨텍스트 설정이 같다면 이전에 로드했던 컨텍스트를 재사용하는 캐싱 기능이 존재한다.별도의 옵션 설정이 필요한 것은 아니고 컨텍스트 설정만 같다면 자동으로 재사용한다. [컨텍스트가 리로딩 되는 케이스]@WebMvcTest( value = [ MemberFindController::class ])class MemberFindControllerTest : BaseMockMvcTest() { @MockBean lateinit var memberFindReadCase: MemberFindReadCase companion..

테스트 커버리지 100% 달성기[1] - 레이어별 100% 달성 과정테스트 커버리지 100% 달성기[2] - 테스트 환경 구축 및 시간 단축테스트 커버리지 100% 달성기[3] - 테스트 코드 가독성 개선1편과 2편에서 커버리지 100% 달성, 테스트 환경 구축, 테스트 코드 성능 개선을 다루었다.많은 시간 공을 들여 작업을 하다 보니 내가 해왔던 방식이 맞는지 검증도 하고 싶었고, 그동안 다루지 않았던 부분을 개선하고 싶기도 하였다. 무엇 보다 나는 아래 두 가지에 대해 검증 하고 싶었다. 커버리지 100%가 prod 코드에 결함이 없다는 것을 보장할 수 있는지가독성 : 테스트 코드가 prod 코드를 잘 설명하고 있는지정답을 낼 수는 없겠지만 항상 위 두 부분에 부족함이 있다고 전제 하고 이 부분을 리..

트랜잭션 전파 속성트랜잭션의 전파속성이란 중첩된 트랜잭션 구조가 나왔을 때, 어떻게 동작 시킬지를 결정하는 속성이다.DB수준에서 중첩 트랜잭션이라는 것은 존재하지 않는다. 부분적으로 sql구문을 롤백시킬수는 있으나 중첩 트랜잭션은 존재하지 않는다.프로그래밍단에서 @Transactional 어노테이션이 부착된 메서드의 중첩 구조가 나타날 수 있고,  스프링에서는 중첩된 구조에서 다양한 옵션으로 트랜잭션을 사용할 수 있게 하며,  완전히 독립적으로 동작할 수 있는 옵션 또한 제공하고 있다. * 앞으로 설명한 용어에서 부모-자식 트랜잭션이라는 표현은 프로그래밍 서버 기준이며 실제 DB에서 부모-자식 트랜잭션이라는 것은 존재하지 않는것에 주의하자. DB 트랜잭션[중첩 트랜잭션 미지원]start transacti..

스프링의 디스패처 서블릿은 http 요청을 적절할 컨트롤러에 위임하는 역할을 한다. 디스패처 서블릿을 제대로 이해하기 위해서는 자바 서블릿, 서블릿 컨테이너, MVC에 대한 사전 지식을 필요로 한다.이에 대한 설명을 먼저 진행하고 디스패처 서블릿에 대해 알아보도록 하겠다.(이왕 하는거 REST 설명까지 넣었다. 물론 서블릿과 연관이 있는것은 아니다.) 자바 서블릿 (java docs)자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그래밍 기술을 서블릿이라고 한다.서블릿은 초기화 init 메서드, 종료 시 destroy 메서드, 클라이언트 요청 request를 처리하고 응답 response를 반환하는 service메서드로 이루어져있다. 서블릿의 주 역할이 클리이언트 요청에 대한 응답을 반환하는 것이..

테스트 커버리지 100% 달성기[1] - 레이어별 100% 달성 과정테스트 커버리지 100% 달성기[2] - 테스트 환경 구축 및 시간 단축테스트 커버리지 100% 달성기[3] - 테스트 코드 가독성 개선 테스트 커버리지 100%를 달성하니 650개 정도의 TC가 쌓였고 이에 따라 테스트 코드 실행 시간도 증가하게 되었다.나의 로컬 컴퓨터 환경에서 평균 2분 50초 정도의 시간이 걸렸다. 테스트 코드를 작성하며 어느정도 시간 단축을 고려하였다고 하지만 2분 50초 가량 되는 시간은 너무 과도하다.테스트 성능 개선을 위해 유명 기술블로그나 여러 포스팅에서 성능 개선 관련 내용들을 찾아보았고,인텔리제이에 프로파일링 기능을 통해 테스트 코드 실행시간을 추적하며 작업 대상을 추려내며 작업을 진행하였다. 결과부터..

테스트 커버리지 100% 달성기[1] - 레이어별 100% 달성 과정테스트 커버리지 100% 달성기[2] - 테스트 환경 구축 및 시간 단축테스트 커버리지 100% 달성기[3] - 테스트 코드 가독성 개선 최근 토스에서 테스트 커버리지 100% 달성한 글과 영상을 보면서 테스트 커버리지 100% 달성의 목표를 세우고 이를 달성하였다.나는 개인적으로 테스트를 굉장히 중요시 생각하여 해당 영상을 보고 도전 해봐야겠다는 생각이 들어 과거에 실사용자들을 대상으로 운영한 서비스를 대상으로 커버리지 100%에 도전하였다. 포스팅 글은 총 3편으로 제공되고 첫번째 글은 레이어별 테스트 대상 소개와 커버리지 100% 달성 과정을 공유하고,두번째 글은 레이어별 테스트 환경 구축 방법과 테스트 시간을 단축한 과정을 소개한..