스프링 프레임워크를 통해 어플리케이션을 개발 시 프레임워크의 도움을 받아 컨테이너에 빈을 등록하고 빈으로 등록된 객체는 스프링이 의존관계에 놓인 객체의 의존성 주입을 대신 진행해주기 때문에 개발자는 좀 더 편리하게 개발을 진행할 수 있다.
이러한 의존성 주입(Dependency Injection)의 방식은 세 가지가 있는데
- 생성자 주입 (Constructor Injection)
- 수정자 주입 (Setter Injection)
- 필드 주입 (Field Injection)
다음과 같은 방식들이 존재하며,
이 중 스프링 프레임워크에서는 생성자 주입(Constructor Injection) 방식을 권장한다.
생성자 주입 방식의 장점은 여러가지가 있지만 그 중에서 테스트 케이스 작성이 용이하다는 내용에 대해 머릿속에 바로 그려지지 않아 글로 작성하고자 한다.
다음과 같은 FieldService 클래스가 있고 해당 클래스는 FieldCaller 클래스에 의존하고 있다.
@Service 어노테이션을 통해 스프링 컨테이너에 빈으로 등록하고, 의존하고 있는 FieldCaller 클래스 또한 @Compnent 어노테이션을 통해 스프링 컨테이너에 빈으로 등록한다.
그리고 @Autowired를 정의하여 스프링에서 해당 클래스에 의존성 주입의 도움을 받을 수 있다.
다음은 FieldService 클래스를 테스트하는 FieldServiceTest 클래스이다.
FieldService 클래스의 인스턴스를 생성하고 해당 인스턴스의 call 메서드를 수행한다.
실행 결과, NullPointerException이 발생한다.
FieldService 클래스에서 call() 메서드를 수행하기 위해 의존하고 있는 FieldCaller 클래스가 의존성 주입이 되지 않았기 때문에 해당 예외가 발생한 것으로 보인다.
해당 테스트 코드를 옳바르게 실행하기 위해선 Mockito를 이용해 목킹을 하여야 한다.
(Mockito를 이용한 테스트 수행)
뒤이어 필드 주입 방식이 아닌 생성자 주입을 이용하여 테스트를 진행해보았다.
앞에서 필드 주입 방식을 사용했던 FieldService 클래스 예제와 동일한 로직이며, 생성자 주입 방식을 필드 주입에서 생성자 주입 방식으로 전환하였다.
※ 생성자 주입 방식에서 단일 생성자일 경우 @Autowired는 생략이 가능하며, 의존하는 필드에 final 키워드를 정의할 수 있다. (반드시 초기화를 해주어야 하고, 컴파일 단계에서 IDE의 도움을 받을 수 있다는 이점이 있다.)
다음은 생성자 주입 방식을 선택한 클래스의 테스트 코드이다.
객체의 인스턴스 생성 시 생성자에 의존성이 필요한 객체를 매개변수로 전달하였고,
Mockito를 이용하지 않고도 순수 자바코드만으로 정상적으로 테스트를 수행할 수 있었다.
의존성 주입은 대부분의 경우에 생성자 주입 방식을 사용하는 것이 옳겠다.
