최근 프로젝트에서 다음 세 가지 종류의 테스트를 작성하고 있다.
- 단위 테스트
- 서버 기능을 확인하기 위한 컨트롤러, 서비스, 리포지토리 등에 대한 통합 테스트
- 웹 브라우저에서 DB까지 모두를 포함한 E2E(end-to-end) 테스트
E2E 테스트를 작성하지 않은 기능은 통합 테스트와 단위 테스트를 기반으로 기능을 완성한 뒤에 직접 수동으로 웹 브라우저에서 테스트를 진행한다. 이 과정에서 한 가지 불편한 점이 있다. 수동으로 테스트를 하려는 시점의 데이터는 이전에 마지막으로 수행한 수동 시점의 데이터가 아니라는 점이다. 예를 들어, 수동 테스트에서 로그인할 때 사용한 'admin' 계정을 통합 테스트 과정에서 비활성화했다면 로그인이 안 되는 그런 식이다.
이런 불편을 줄이려고 사용한 방법은 다음의 두 가지 정도다.
- DB 구분
- 수동으로 데이터 초기화
자동화된 테스트와 수동 테스트에서 사용하는 DB를 구분하는 방법은 메이븐과 같은 빌드 도구의 프로필이나 스프링 프로필을 사용해서 처리한다. 이 방식을 사용하면 개발 과정에서 실행한 테스트 코드가 DB 상태를 변경해도, 수동 테스트에서 사용할 데이터는 영향을 받지 않는다. 내가 이전에 웹 브라우저에서 확인한 마지막 상태에서 다시 시작할 수 있어, 맥이 끊기지 않는 느낌을 받았다.
반면에 개발 과정에서 자동화 테스트용 DB의 스키마를 변경하면 수동 테스트용 DB 스키마를 함께 변경해 주어야 한다. 이 단점은 Flyway나 Liquibase와 같은 도구를 완화할 수 있다.
자동화된 테스트와 수동 테스트에서 사용하는 DB가 같다면, 수동 테스트를 시작하기 전에 데이터를 수동 테스트에 알맞은 상태로 되돌리는 방법을 사용한다. 초기화를 위한 SQL 파일을 하나 만들고 이 파일을 수동 테스트 전에 실행하는 방식을 주로 사용한다. 로컬 서버를 구동할 때 옵션을 주면 SQL 파일을 실행하는 방법도 사용해봤다. 이 방법은 서버 구동 시점에 데이터를 초기화하니까 편한데, 대신 습관적으로 서버 실행 명령어를 입력하다보면 원치 않게 데이터가 초기화되는 상황이 종종 발생하기도 한다.
하다보면 두 방식을 혼용해서 사용하고 싶어진다. 방식이 늘어나면 뭔가 더 많이 하는 것 같아 거부감이 들기도 하지만, 테스트 코드가 그런 것처럼 결과적으로 개발 시간을 줄여주는 효과를 준다.