Test

JUnit5에 @BeforEach를 적용한 메서드에 다음과 같은 코드를 추가하고 실행해 보았다.

출력된 context값과 this의 오브젝트 값을 확인하면 context는 3번 모두 동일한 객체를 보여주고 있고.

각 테스트에 대한 객체는 각각 새로운 테스트 객체를 반환하는 것을 확인할 수 있다.

 

왜 context는 한번일까? JUnit의 확장 기능인 @ExtendWith는 테스트가 실행되기 전에 딱 한 번만 애플리케이션 콘텍스트를 만들고, 테스트 오브젝트가 만들어질 때마다 애플리케이션 콘텍스트 자신을 테스트 오브젝트의 특정 필드에 주입해준다. 

 

* 스프링은 설정파일의 종류만큼 애플리케이션 콘텍스트를 만들어 같은 속성을 공유하는 테스트 객체에게 동일한 콘텍스트를 주입해 준다.

 

@Autowired를 사용하면 타입이 일치하는 빈이 있으면 인스턴스 변수에 자동으로 주입해준다. 또한 스프링 애플리케이션 콘텍스트는 초기화할 때 자기 자신도 빈으로 등록하기 때문에 굳이 인스턴스 변수를 주입받을 필요가 없다.

 

 

테스트에도 느슨하게 연결관계를 가져가는 것이 미래를 보는 방법이다. 

왜냐하면 개발에서 절대로 변경되지 않는다는 것은 없다. 또한 인터페이스를 두고 DI를 적용하게 둔다면 새로운 서비스 기능을 도입할 때 더욱 쉽게 서비스를 추가할 수 있다.

 

만약 DI를 테스트 단계에서 직접 수정하고 싶다면 @DirtiesContext 어노테이션을 사용할 수 있다 클래스 혹은 메소드에 붙일 수 있다. 콘텍스트의 상태를 변경하는 범위에 따라 해당 어노테이션의 위치를 결정할 수 있다. 대신 실행될 때마다 변경된 애플리케이션이 생성되고 소멸된다.

 

 

DI를 활용하여 테스트를 사용할 때 적용 환경에 따라 추천되는 방식이 존재한다.

 

가장 먼저 고려하는 것은 스프링 컨테이너 없이 테스트할 수 있는 방법이다. 가장 간결하게 수행할 수 있고 검증할 수 있다.

여러 오브젝트와 복잡한 연관관계를 가지고 있다면 스프링 컨테이너를 사용한 DI방식의 테스트를 이용하자. 테스트에서 애플리케이션 컨텍스트를 사용하는 경우에는 테스트 전용 설정 파일을 따로 만들어 사용하는 편이 좋다.

마지막으로 강제로 의존관계를 구성해야하는 경우는 @DirtiesContext를 사용하여 구성하면 된다.