05. flyway 설정과 DAO 테스트

본인은 Dao에 대한 테스트 코드를 만드는 것에 부정적이다. Dao 레벨의 테스트는 의미를 찾기가 어렵기 때문이다. 어떤 기능을 한다는 것은 Dao 레벨에서 만들어지는 단순한 기능이 아니라 여러가지 단순한 기능들을 엮어 하나의 의미있는 동작을 만들어야 하기 때문이다. 따라서 테스트의 단위는 의미있는 기능이 만들어지는 서비스 레벨에서 부터 이루어져야 하지 않을까? 더구나 Spring Data가 만들어내는 자동화 코드를 테스트할 의미가 있을까 싶다. 그러나 여기서는 Dao를 테스트 하므로써 Spring Data가 만들어내는 코드와 QueryDSL이 실제 동작하는지 살펴보고, flyway가 어떻게 개발환경 구축에 도움을 주는지 살펴볼 것이다.



1. flyway 설정과 테스트 데이터 입력


flyway는 기초 데이터를 넣어주는 유틸리티라고 생각하면 된다. 프로그램의 구동이 시작될 때 주어진 스크립트 파일을 하나씩 순서대로 실행해 준다. 여기서는 첫번째 파일에 DDL 스크립트를 넣고, 두번째 파일에는 기초데이터를 넣었다. 이 기능을 위해 대상 DB에 스크립트의 버전을 관리하는 테이블을 flyway가 스스로 만들어 둔다. 아래는 실행 스크립트를 만드는 방법이다.


flyway에 실핼 시킬 스크립트는 일반적으로 /resources/db/migration 아래 넣는 것이 기본 설정 사항이지만, 여기서는 따로 설정할 수 있도록 filesystem에 지정하였다. 50번 라인이 그것이다.

스크립트는 DDL 부분과 기초 데이터 insert 부분을 각각 따로 만들었다. 파일명은 규칙에 따라 V1__demo-initial-schema.sql 과 V2__demo-initial-data.sql으로 나눴다. ddl 스크립트는 hibernate 구동 시 생성되는 스크립트를 로그에서 복사하여 붙였으며, insert 문장은 ddl 문장에 맞춰서 작성 하였다.

V1__demo-initial-schema.sql 

V2__demo-initial-data.sql



2.DAO 테스트

아래 테스트하는 코드는 SpringSecurity에 사용할 메소드들이다. 더 추가되거나 변경될 수 있지만, 일단 생각나는 대로 작성했다. 테스트 코드를 보면 매우 엉성해 보일지도 모르겠다. 그러나 테스트 코드는 이정도 수준으로 작성하는 것이 옳다는 생각을 한다. 더 정교하고 완벽한 테스트 코드는 많은 시간과 노력이 들어가기 때문에 잘못하면 배보다 배꼽이 더 커지는 현상이 있다. 테스트에서 해야할 것은 원하는 동작을 오류 없이 수행 가능한 것인지를 확인하는 것 뿐이다.


테스트 코드를 작성할 때 주의할 점이 있다. 테스트 메소드는 다른 메소드와 연동되어 수행되면 안되고, 반드시 그 자체로 완결되어야 한다. 그렇지 않으면 작업이 진행되면서 계속 변화하고 추가되면 기능들로 인하여 빈번히 테스트를 수정해야 하는 상황이 발생한다. 그런 상황들은 테스트 코드를 만드는 것을 지치게 한다.


24번/25번 라인은 SpringBoot 환경에서 테스트할 환경을 조성해 주는 어노테이션이다. 26번 라인은 Lombok에서 제공하는 어노테이션으로 간편하게 로그를 찍을 수 있게 도와준다. 27번 라인의 @Transactional 어노테이션은 테스트를 수행하면서 더러워진(?) 데이터를 처음 상태로 만들어준다. 즉, 수행된 쿼리를 롤백 시켜준다. @Transactional 어노테이션을 지우면 테스트로 인해 변경된 데이터가 그대로 남게 된다. 28번 라인의 @FixMethodOrder 어노테이션은 테스트 메소드를 이름 순서대로 실행 시켜준다. 이것이 없을 경우는 어떤 테스트가 먼저 실행될 것인지 알 수 없다. 37번 라인의 @Test 어노테이션은 테스트 대상 메소드라는 것을 알린다. 

38번 라인에 선언된 메소드를 주의깊게 봐줬으면 한다. 앞 부분은 테스트 번호를 붙인 것이지만 뒤에는 한글로 테스트 명을 입력하였다. 이렇게 한글로 메소드명을 입력하면 따로 주석을 달지 않아도 직관적으로 무슨 테스트인지 확인할 수 있기 때문에 편리하다. 

40번과 65번 라인은 수행된 결과를 확인하는 문장이다. 이런 Assert 메소드는 여러가지 종류가 있지만, 본인을 이 두 메소드 외에는 별로 사용하지 않는다. 이유는 앞에서도 설명 했듯이 테스트 코드에 많은 시간과 노력을 들이고 싶지 않기 때문이다. 처한 여건이나 상황에 따라 다르겠지만, 적당한 테스트 수준을 유지하는 것이 테스트 코드의 진짜 핵심이지 않을까 싶다.



첨부파일은 본 페이지를 만들기 위한 소스다.

demo.zip