일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- wildfly
- Windows
- dbeaver
- jetbrains
- tibero
- gson
- JPA
- react
- gradle
- Java
- log4j2
- nginx
- intellijIDEA
- docker
- kubectl
- useEffect
- Git
- VSCode
- springboot
- database
- JavaScript
- nodejs
- BPMN
- Spring
- LOG4J
- IntelliJ
- MySQL
- mybatis
- NCP
- Kubernetes
- Today
- Total
두 손끝의 창조자
[스프링 테스트] No bean named 'myBean' available 본문
A 테스트 클래스에서는 @ContextConfiguration(classes = {AppConfig.class})
형태로 컨택스트를 가져오고 B 테스트 클래스에서는 @ContextConfiguration(/applicationContext.xml
형태로 컨택스트를 가져오도록 설정했을 때, A와 B클래스 테스트 실행 순서에 따라서 AppConfig
클래스 설정정보를 먼저 로드하거나 applicationContext.xml
의 설정정보를 로드하게 된다.
문제는 두 설정 정보가 똑같다면 상관없지만 다르다면 A또는 B테스트에서 설정이 정확하게 세팅이 안된다. 왜냐하면 컨텍스트 두개를 동시에 불러서 테스트 컨텍스트에 올리지 않기 때문에다. 먼저 올라온 놈이 먼저 세팅되고 하나는 무시된다.
이 문제를 해결하기 위해서 A와 B 클래스에 @DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE\_CLASS)
와 같은 애노테이션으로 컨텍스트 자체를 다시 로드하게 할 수 있다.
하지만 이 방법은 모든 테스트 클래스에 대해서 설정해줘야하고 매번 재설정 되기 때문에 성능적으로 비효율 적이다. 용도대로 컨텍스트내 싱클톤 클래스내 정보가 변경시킨다던지 했을 때만 사용하는 것이 좋다.
두 번째 방법은 컨텍스트 로딩 순서를 제어하는 것이다. 예를 들어서 B 테스트 클래스에서는 applicationContext.xml
을 기본으로하고 추가적인 사항을 AppConfig
클래스에서 가져오도록 컨텍스트 계층을 설정하는 것이다.
@ContextHierarchy({
@ContextConfiguration(classes = {AppConfig.class}),
@ContextConfiguration("/applicationContext.xml")
})
와 같은 형태가 된다. 이렇게 하면 AppConfig
에서 먼저 빈을 등록하고 applicationContext.xml
에서도 필요한 빈을 추가로 등록한다.