[토비의 스프링 3.1] 2.1 UserDaoTest 다시 보기

스프링이 제공하는 가장 중요한 가치로 객체지향과 테스트를 꼽을 수 있다.
실제로 테스트를 작성할 때 JUnit 프레임워크를 사용했는데 손쉽게 사용할 수 있었다.

2장에서는 테스트의 가치, 활용 전략, 스프링과의 관계를 살펴본다.

2.1.1 테스트의 유용성

기존 1장에서 개발한 UserDao가 잘 동작하는지 확인하기 위해 테스트 코드를 작성했었다.
main() 메소드를 이용해 UserDao를 직접 호출해서 add(), get() 메소드의  결과를 System.out.println()으로 콘솔에 출력해 눈으로 확인했었다.

웹을 통한 DAO 테스트 방법의 문제점

DAO를 테스트하고 싶은데 서비스, MVC 프레젠테이션 계층 등을 작성하고 테스트용 웹 서버에 배치한 뒤, 폼을 띄워 값을 입력해야 한다면 당연히 제대로 된 테스트를 진행하기 힘들 것이다. 

에러가 발생해도 그 원인을 자세히 파악하기 힘들고, DAO를 테스트하는데 필요한 요구사항이 너무 많다.

작은 단위의 테스트

따라서 단위 테스트(작은 단위에 집중)를 수행해야 한다. 그 단위는 작을수록 좋다. 단위를 넘어서는 다른 코드들을 배제시키고 테스트가 동작할 수 있으면 좋다. 

단위 테스트를 통해 개발자는 본인이 설계한 코드가 의도대로 동작하는지 빨리 확인받을 수 있다. 
물론 사용자 인터페이스부터 DB에 이르는 전 계층이 참여하는 테스트도 필요하다. 

자동수행 테스트 코드

다행히 main() 메소드로 진행하는 테스트는 테스트의 전 과정을 자동으로 진행한다. 만약 웹 화면에 폼을 띄우고, 등록하는 값을 직접 입력하고, 전송or 조회 버튼을 직접 눌러서 테스트해야 한다면 그 과정이 너무 고될 것이다.

따라서 테스트는 자동으로 수행되도록 코드로 만들어지는 것이 중요하다. 신나게 반복적으로 테스트를 수행할 수 있다.

2.1.3 UserDaoTest의 문제점

main()메소드를 통해 테스트가 자동으로 이루어지는 장점은 있으나 단점도 몇 가지 존재한다.

• 수동 확인 작업의 번거로움
  
  UserDaoTest는 결과를 콘솔에 출력한다. 그리고 개발자가 결과를 두 눈으로 확인하는 과정이 필요하다. 값이 일치하는지 테스트는 보장해주지 못하고 단지 출력만 해줄 뿐이다. 검증해야 하는 양이 많고 복잡해지면 불편함을 느낄 수 밖에 없으며 실수하기 마련이다.
  
  
• 실행 작업의 번거로움
  
  간단한 main 메소드여도 매번 그것을 실행하는 것은 제법 번거롭다. DAO가 수백 개가 되고 그에 대한 main 메소드도 수백 개라면..?

 

다음 2.2장 포스팅에서는 UserDaoTest를 개선하는 내용을 다룬다.