Junit 4 를 쓰기 시작하면서, dbunit을 연동할때도, 코드상의 변화가 생겼다.
특별히 Junit 3.* 대와 연동했을때와 비교하여 특별하게 달라진 건 없지만, 조금 간결해진것 같다.
DBUnit을 사용하기 위해서는 추가로 slf4j 라이브러리가 필요하다.
slf4j 는 commons-logging 과 같은 로깅을 확장(facade) 해주는 라이브러리로, commons-logging 보다 더 많은 로깅 패키지들을 지원한다.
사실, 로깅 패키지들이 너무 많이 생겨나는 것보다, 하나의 킬러 로깅 패키지만 존재했으면 좋겠다.
(일일히 배우기 귀찮으니깐..)
이번 테스트의 흐름은.
1. 원하는 결과를 담은 XML 데이타 작성
(미리 디비에 값을 넣어보고, export tool 을 사용해서 뽑아냈다.)
2. Junit 테스트 전에 (@before Class 시점에서)
디비안의 목표 테이블을 truncate 한뒤에, 위에서 만든 XML 데이타를 넣었다.
XML 데이타를 밀어넣은 이유는, 내가 테스트 할려는 메소드가 Select 쿼리를 날리는 메소드이므로,
디비 안에 테스트 데이타가 필요해서 였다.
3. 테스트할 메소드 실행
4. 테스트
특별히 Junit 3.* 대와 연동했을때와 비교하여 특별하게 달라진 건 없지만, 조금 간결해진것 같다.
DBUnit을 사용하기 위해서는 추가로 slf4j 라이브러리가 필요하다.
slf4j 는 commons-logging 과 같은 로깅을 확장(facade) 해주는 라이브러리로, commons-logging 보다 더 많은 로깅 패키지들을 지원한다.
사실, 로깅 패키지들이 너무 많이 생겨나는 것보다, 하나의 킬러 로깅 패키지만 존재했으면 좋겠다.
(일일히 배우기 귀찮으니깐..)
이번 테스트의 흐름은.
1. 원하는 결과를 담은 XML 데이타 작성
(미리 디비에 값을 넣어보고, export tool 을 사용해서 뽑아냈다.)
2. Junit 테스트 전에 (@before Class 시점에서)
디비안의 목표 테이블을 truncate 한뒤에, 위에서 만든 XML 데이타를 넣었다.
XML 데이타를 밀어넣은 이유는, 내가 테스트 할려는 메소드가 Select 쿼리를 날리는 메소드이므로,
디비 안에 테스트 데이타가 필요해서 였다.
3. 테스트할 메소드 실행
4. 테스트
full-dataset.xml
ListHandlerTest.Java
ListHandler.Java