책을 보면 다음과 같은 구절이 있습니다.

"스프링이 개발자에게 제공하는 가장 중요한 가치가 무엇이냐고 질문한다면 나는 주저하지 않고 객체지향과 테스트라고 대답할 것이다"

테스트는 개발자가 작성한 코드를 확신할 수 있게 해주고, 변화에 유연하게 대처할 수 있는 자신감을 주기에 없어서는 안 될 기술입니다.

또한, 테스트를 자동화하지 않는다면 매번 기능 추가/수정할 때마다 사람이 직접 기능테스트를 하는데 이것은 사실 불가능에 가깝습니다.

스프링 테스트

기존에 마음놓고 리팩토링한 UserDaoTest 를 확인해보겠습니다.

public class UserDaoTest {
    public static void main(String[] args) {
        try {
            ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
            UserDao userDao = context.getBean("userDao", UserDao.class);

            //user 삽입
            User newUser = User.builder()
                    .id("test")
                    .nickName("junhan")
                    .build();

            userDao.add(newUser);
            
            //user 조회
            User user = userDao.findById(newUser.getId());
            String nickName = Optional.ofNullable(user)
                    .map(User::getNickName)
                    .orElse(null);
            System.out.println("user nickName >> " + nickName);

            //user 삭제
            userDao.deleteById(newUser.getId());

            //삭제 후 user null
            System.out.println("user empty >> " + userDao.findById(newUser.getId()));
        } catch(Exception e) {
            e.printStackTrace();
        }
    }
}

물론 main 메서드 안의 로직이 계속 변경되긴 했지만 (UserDao 객체를 직접 생성하는 것 -> ApplicationContext 를 이용하는 방식) UserDao 의 기능을 main 메서드를 통해 소스를 고칠 때 할 때마다 제대로 동작하는지 실행해봤기에 그나마 안심하며 고칠 수 있었습니다.

그러나 위의 main 메서드로 테스트를 하기에는 문제점이 많습니다.

우선, 매번 실행 결과를 사람의 눈으로 확인해야합니다.

위에서도 UserDao 메서드의 출력 값을 System.out.println 메서드를 사용하여 출력할 뿐 그 결과가 맞는지는 사람이 직접 확인해야합니다.

또한, UserDao 외의 다른 DAO 클래스, 또는 다른 계층의 클래스들이 추가될 때, main 메서드를 가진 클래스도 그만큼 만들어주어야 합니다.

아무리 main 메서드를 간단하게 작성할 수 있다고 해도, 매번 그 main 메서드를 하나씩 실행하는 것도 비효율적인 일입니다.

그리고 DAO 테스트의 경우에는 운영 DB 가 아닌 테스트 DB 에서 진행해야 하는데, 이에 대한 설정을 바꾸려면 그것 또한 번거로운 작업이 될 것입니다.

이와 같은 문제점이 있기에 보통 테스트를 하기 위해서는 프레임워크를 이용하는데요