스프링 테스트 컨텍스트 프레임워크
- 스프링의 JUnit 확장기능은 테스트가 실행되기 전에 딱 한번만 애플리케이션 컨텍스트를 만들어두고, 테스트 오브젝트가 만들어질 때마다 특별한 방법을 이용해 애플리케이션 컨텍스트 자신을 테스트 오브젝트의 특정 필드에 주입해줌
- 여러 개의 테스트 클래스에서 같은 설정파일을 가진 애플리케이션 컨텍스트를 사용하면, 스프링은 테스트 클래스 사이에서 애플리케이션 컨텍스트를 공유하게 해줌
- ApplicationContext가 Autowired 가능한 이유는 스프링 애플리케이션 컨텍스트가 초기화 할 때 자기 자신도 빈으로 등록하기 때문임
- @Autowired에서 해당 타입의 빈이 여러개 있을 때, 변수이름과 동일한 빈이 주입됨
Datasource dataSource→ dataSource 라는 이름의 빈이 주입됨
테스트 코드에 의한 DI
- 하나의 애플리케이션 컨텍스트에서 테스트 시 다른 빈을 사용하기 위해 테스트 코드 안에서 특정 빈의 의존관계를 변경하는 것.
- 이 때,
@DirtiesContext어노테이션도 추가해주어야 함. 해당 클래스의 테스트에서 애플리케이션 컨텍스트의 상태를 변경한다는 것을 알려주는 것임 - 테스트 컨텍스트는 이 애노테이션이 붙은 테스트 클래스에는 애플리케이션 컨텍스트 공유를 허용하지 않음
테스트를 위한 별도의 DI 설정
- 그러나 이렇게 계속 코드에서 변경하는 것은 좋지 않음 → application-test.xml 설정을 만들자!
@SpringBootTest @ActiveProfiles("test") // application-test.yaml 파일을 찾아서 설정이용함 public class UserDaoTest {
컨테이너 없는 DI 테스트
- 스프링 컨테이너 없이 테스트 코드의 수동 DI만을 이용해 테스트 코드를 만들면 ApplicationContext를 만드는 작업이 없기 대문에 더 빠르게 테스트가 가능함
- DI는 객체지향 프로그래밍 스타일이기에 DI를 위해 컨테이너가 반드시 필요한 것은 아님
DI를 이용한 테스트 방법 선택
- 항상 스프링 컨테이너 없이 테스트할 수 있는 방법을 가장 우선적으로 고려하기
- 테스트를 위해 필요한 오브젝트의 생성과 초기화가 단순하다면 이 방법을 가장 먼저 고려
- 여러 오브젝트와 복잡한 의존관계를 갖고 있는 오브젝트를 테스트해야 할 경우가 있을 때는 스프링의 설정을 이용한 DI 방식의 테스트를 이용하면 편리함
- 테스트 설정을 따로 만들었다고 하더라도 때로는 예외적인 의존관계를 강제로 구성해서 테스트해야 할 경우가 있음. 이 때는 컨텍스트에서 DI 받은 오브젝트에 다시 테스트 코드로 수동 DI 해서 테스트.
@DirtiesContext애노테이션 사용하기
학습 테스트
- 자신이 만들지 않은 프레임워크나 다른 개발팀에서 만들어서 제공한 라이브러리 등에 대해서도 테스트를 작성해야 함. 이러한 테스트를 학습 테스트라고 함
- 학습 테스트의 목적은 자신이 사용할 API나 프레임워크의 기능을 테스트로 보면서 사용 방법을 익히려는 것
- 장점
- 다양한 조건에 따른 기능을 손쉽게 확인해 볼 수 있음
- 학습 테스트 코드를 개발 중에 참고할 수 있음
- 프레임워크나 제품을 업그레이드 할 때 호환성 검증을 도와준다!!
- 테스트 작성에 대한 좋은 훈련이 된다
- 새로운 기술을 공부하는 과정이 즐거워진다
- 어떤 기술이든 마찬가지지만 특히 스프링은 문서만 가지고 공부해서는 쉽게 이해하고 익히기 힘들다. 실전에 적용하기 전에 스프링의 기능을 사용한 테스트를 가능한 한 많이 만들어보자
버그 테스트
- 코드에 오류가 있을 때 그 오류를 가장 잘 드러내 줄 수 있는 테스트를 말함
- QA 팀의 테스트 중에 기능 오류가 발견되었을 시, 무턱대고 코드를 뒤져가면서 수정하려고 하기 보다는 먼저 버그 테스트를 만들어보는 편이 유용함
- 버그 테스트는 일단 실패하도록 만든 뒤, 테스트가 성공하도록 애플리케이션 코드를 수정
- 장점
- 테스트의 완성도를 높여줌
- 버그의 내용을 명확하게 분석하게 해줌
- 기술적인 문제를 해결하는 데 도움이 됨