주요글: 도커 시작하기

최근 프로젝트에서 다음 세 가지 종류의 테스트를 작성하고 있다.

  • 단위 테스트
  • 서버 기능을 확인하기 위한 컨트롤러, 서비스, 리포지토리 등에 대한 통합 테스트
  • 웹 브라우저에서 DB까지 모두를 포함한 E2E(end-to-end) 테스트
통합 테스트나 E2E 테스트를 작성하다보면 테스트 목적에 맞게 @Before나 테스트 대상 기능을 실행하기 전에 DB를 원하는 상태로 변경한다. DB 상태를 맞추기 위해 테이블을 비우거나(truncate), 특정 조건의 데이터를 지우거나 추가한다.

E2E 테스트를 작성하지 않은 기능은 통합 테스트와 단위 테스트를 기반으로 기능을 완성한 뒤에 직접 수동으로 웹 브라우저에서 테스트를 진행한다. 이 과정에서 한 가지 불편한 점이 있다. 수동으로 테스트를 하려는 시점의 데이터는 이전에 마지막으로 수행한 수동 시점의 데이터가 아니라는 점이다. 예를 들어, 수동 테스트에서 로그인할 때 사용한 'admin' 계정을 통합 테스트 과정에서 비활성화했다면 로그인이 안 되는 그런 식이다.


이런 불편을 줄이려고 사용한 방법은 다음의 두 가지 정도다.

  • DB 구분
  • 수동으로 데이터 초기화

자동화된 테스트와 수동 테스트에서 사용하는 DB를 구분하는 방법은 메이븐과 같은 빌드 도구의 프로필이나 스프링 프로필을 사용해서 처리한다. 이 방식을 사용하면 개발 과정에서 실행한 테스트 코드가 DB 상태를 변경해도, 수동 테스트에서 사용할 데이터는 영향을 받지 않는다. 내가 이전에 웹 브라우저에서 확인한 마지막 상태에서 다시 시작할 수 있어, 맥이 끊기지 않는 느낌을 받았다.


반면에 개발 과정에서 자동화 테스트용 DB의 스키마를 변경하면 수동 테스트용 DB 스키마를 함께 변경해 주어야 한다. 이 단점은 Flyway나 Liquibase와 같은 도구를 완화할 수 있다.


자동화된 테스트와 수동 테스트에서 사용하는 DB가 같다면, 수동 테스트를 시작하기 전에 데이터를 수동 테스트에 알맞은 상태로 되돌리는 방법을 사용한다. 초기화를 위한 SQL 파일을 하나 만들고 이 파일을 수동 테스트 전에 실행하는 방식을 주로 사용한다. 로컬 서버를 구동할 때 옵션을 주면 SQL 파일을 실행하는 방법도 사용해봤다. 이 방법은 서버 구동 시점에 데이터를 초기화하니까 편한데, 대신 습관적으로 서버 실행 명령어를 입력하다보면 원치 않게 데이터가 초기화되는 상황이 종종 발생하기도 한다.


하다보면 두 방식을 혼용해서 사용하고 싶어진다. 방식이 늘어나면 뭔가 더 많이 하는 것 같아 거부감이 들기도 하지만, 테스트 코드가 그런 것처럼 결과적으로 개발 시간을 줄여주는 효과를 준다.

+ Recent posts