스프링에서의 테스트
스프링은 IoC/DI를 이용해 엔터프라이즈 애플리케이션을 효과적으로 개발하기 위한 기술이다.
복잡한 엔터프라이즈 애플리케이션을 개발하는데 스프링이 제공하는 주요 기술은 2가지 이다.
- 객체지향 기술 (IoC / DI)
- 테스트
애플리케이션은 계속 변하고 복잡해져 간다. 그 변화에 대응할 수 있는 방법은 2 가지 이다.
- 확장과 변화를 고려한 객체지향적 설계와 그것을 구현할 수 있는 IoC/DI 기술
- 변화한 코드에 대한 확신을 줄 수 있는 테스트 기술
2.1 main (UserDaoTest) 다시보기
2.1.1 테스트의 유용성
1장에서 만든 UserDao가 기대했던 대로 동작하는지 확인하기 위해 간단한 테스트 코드 (main 클래스)를 만들었다.
해당 테스트 코드는 UserDao 코드의 구조와 설계, 적용한 기술이 변경되더라도 초기 테스트 코드의 목적에 맞게 DB에 사용자 정보를 등록하고, 가져오는 기능을 잘 수행하는지를 테스트 하는 것 이었다.
테스트 : 내가 예상하고 의도했던 대로 코드가 정확히 동작하는지를 확인해서, 만든 코드를 확신할 수 있게 해주는 작업이다.
2.1.2 main (UserDaoTest)의 특징
1장에서 만들었던 main( ) 테스트 코드 이다.
public class main {
public static void main(String[] args) throws SQLException, ClassNotFoundException {
ApplicationContext context = new GenericXmlApplicationContext("applicationContext.xml");
UserDao userDao = context.getBean("userDao", UserDao.class);
// insert test
User user = new User();
user.setId("Id");
user.setName("test_name");
user.setPassword("Password");
userDao.add(user);
System.out.println(user.getId() + "등록 성공");
// select test
User searchedUser = userDao.get(user.getId());
System.out.println(searchedUser.getName());
System.out.println(searchedUser.getPassword());
System.out.println(searchedUser.getId() + "조회 성공");
}
}이 테스트 코드 내용을 정리해보면 다음과 같다.
- 자바에서 가장 손쉽게 실행 가능한 main( ) 메소드를 이용한다.
- 테스트할 대상인 UserDao의 오브젝트를 가져와 메소드를 호출한다.
- 테스트에 사용할 입력 값(User 오브젝트)를 직접 코드에서 만들어준다.
- 테스트의 결과를 콘솔에 출력해준다.
- 각 단계의 작업이 에러 없이 끝나면 콘솔에 성공 메시지로 출력해준다.
웹을 통한 DAO 테스트 방법의 문제점
보통 웹 프로그램을 통해서 DAO를 테스트 하는 방법은 다음과 같다.
- DAO, 서비스 계층, MVC 프레젠테이션 (View 부분) 까지 포함한 모든 입출력 기능을 구현 후 코드를 실행한다.
- View 부분에서 실제 입력값을 입력하여 원하는 결과값이 다시 View에 출력 되는지 테스트 한다.
이렇게 웹 프로그램을 통해서 테스트 하는 방법은 DAO에 대한 테스트로서는 단점이 너무 많다.
- DAO뿐만 아니라 모든 레이어의 기능을 다 만들고 나서야 테스트가 가능하다.
- 하나의 테스트를 위해 참여하는 코드가 너무 많아진다.
- 테스트 도중 에러 발생 시, 어디에서 문제가 발생했는지 찾아야 하는 수고가 필요하다.
그렇다면 테스트를 어떻게 만들면 이런 문제를 피할 수 있고, 효율적으로 테스트를 활용할 수 있는지 생각해보자.
작은 단위의 테스트
테스트 하고자 하는 대상이 명확하다면 그 대상에만 집중해서 테스트하는 것이 바람직하다.
- 테스트는 가능한 작은 단위로 쪼개서 집중해서 해야한다.
- 테스트의 관심이 다르다면 테스트할 대상을 분리하고 집중해서 접근해야 한다. (관심사의 분리)
단위 테스트 : 하나의 단위 코드에 대해 테스트를 수행하는 것
- 단위 : 충분히 하나의 관심에 집중해서 효율적으로 테스트할 만한 범위의 단위
- 일반적으로 단위는 작을수록 좋다.
- 통제할 수 없는 외부의 리소스에 의존하는 테스트는 단위 테스트가 아니라고 보기도 한다.
- 테스트 할때마다 DB의 상태가 달라지고, 테스트를 위해 DB를 특정 상태로 만들어 줄 수 없는 경우
- 때로는 여러 단위가 묶인 하나의 과정을 테스트 하기 위한 테스트도 필요하다.
- 이런 긴 단위의 테스트는 수행하기 전, 각 짧은 단위 테스트를 검증을 한다면. 더 수월하게 에러를 잡을 수 있다.
자동수행 테스트 코드
main(UserDaoTest)의 한 가지 특징은 main( )메소드를 실행하는 가장 간단한 방법만으로 테스트의 전 과정이 자동으로 진행된다.
웹을 통한 테스트를 수행하게 되면, 객체 생성 부터 화면 조회까지 개발자 스스로 입력하고 확인해야 하는 번거러운 작업을 테스트 마다 반복해야 한다.
이렇게 테스트는 자동으로 수행되도록 코드로 만들어지는 것이 중요하다.
- 별도로 테스트용 클래스를 만들어서 테스트 코드를 넣어둔다.
장점
- 자주 반복할 수 있다.
- 테스트를 빠르게 실행하고 결과를 쉽게 확인할 수 있다.
지속적인 개선과 점진적인 개발을 위한 테스트
1장에서 처음 만든 초난감 DAO코드에서 부터 스프링을 이용한 최종 코드까지 발전시키는 과정의 일등 공신은 바로 이 테스트였다.
테스트가 없었다면, 다양한 코드를 수정하고 설계를 개선해나가는 과정에 확신을 가질 수 없었을 것이다.
테스트를 이용하면
- 새로운 기능이 기대한 대로 동작하는지 확인할 수 있다.
- 기존에 만들어뒀던 기능들이 새로운 기능을 추가하느라 수정한 코드에 영향을 받지 않고 여전히 잘 동작하는지 확인할 수 있다.
2.1.3 main (UserDaoTest)의 문제점
수동 확인 작업의 번거로움
main( ) 테스트를 위한 입력 데이터의 준비와 테스트 수행과정은 모두 자동으로 수행된다.
하지만, 테스트 결과를 확인하기 위해서는 개발자가 직접 콘솔을 확인해야 한다.
실행 작업의 번거로움
만약 DAO가 수백 개가 되고 그에 대한 테스트를 위해 main( )메소드도 그만큼 만들어진다면.
전체 기능을 테스트해보기 위해 main( )메소드를 수백번 실행하는 수고가 필요하다.
또한 그 결과를 눈으로 확인하기도 번거로운 작업이다.
