각 통합 테스트 후 스프링 컨텍스트가 더럽습니다.

Question

최근에 현재 프로젝트에서 프리랜서로 시작했습니다. 내가 던진 일 중 하나는 실패한 젠킨스 (Jenkins) 빌드 (4 월 8 일부터 시작했는데, 여기에서 시작하기 1 주일 전부터 실패한 것입니다.)였습니다.

일반적으로 말해서 로그에 DI 문제가 표시 될 수 있습니다. 내가 한 첫 번째 작업은 모든 테스트가 동일한 애플리케이션 컨텍스트에서 시작하여 같은 방식으로 작동하도록하는 것이 었습니다. 그들은 또한 올바르게 작동하지 않는 것처럼 보인 자신의 "조롱"을 구현했습니다. 리드 개발자와의 토론 후 Springockito 사용을 제안했습니다. (특정 모듈의 경우 통합 테스트를 위해 조롱이 필요했습니다. 기존의 이유는 변경할 수 없습니다.)

어쨌든, 그 후에 나쁘게 실패하기 시작했습니다. 테스트에서 조롱을받은 많은 콩들이 조롱받지 않았거나 발견되지 않았습니다. 일반적으로 하나 또는 다른 bean이 누락되었다는 것을 나타내는 응용 프로그램 컨텍스트로드시 실패합니다.

나는 다양한 시도와 다른 접근법을 시도했지만, 결국 가장 걱정되는 것 : 모든 단일 테스트에 @DirtiesContext를 추가하십시오. 이제, Maven 빌드가 다시 초록색으로 변하기 시작합니다. 테스트는 그들이하는 일을 시작합니다. 하지만 컨텍스트가 약 1-2 초 안에로드되기 때문에 시간이 걸리는 Spring 컨텍스트를 매번 다시로드하고 있습니다.

이 기사에 대한 부수적 설명은 Hibernate 4로 업그레이드되어 Spring 3.2로 업그레이드되었다는 점입니다. 이전에는 Spring 3의 이전 버전을 사용하고있었습니다. 모든 테스트가 그 당시에 작동하고 있었고 @DirtiesContext는 필요하지 않았습니다.

가장 이상한 점은이 이상한 행동에 대한 설명을 즉시 생각할 수 없다는 것입니다. @Autowired beans를 사용하는 테스트를 시작하기 만하면 스프링 컨텍스트가 더러워진 것 같습니다. 모든 테스트가 모의 (Mock)를 사용하는 것은 아니기 때문에 그렇게 할 수는 없습니다. 누구에게도 익숙한 소리입니까? 누구나 (최신 버전의) Spring과의 통합 테스트 경험이 있습니까?

Stackoverflow에서이 티켓을 찾았습니다 : How can a test 'dirty' a spring application context? 내가 보는 행동을 요약하는 것처럼 보입니다.하지만 요점은 우리가 서비스/저장소 /를 autowiring하고 있다는 것입니다. 그 수업에는 어떤 세터도 없다.

의견이 있으십니까?

감사합니다.

Answer 1

내 자신의 질문에 대답하기 위해 비밀은 Spring 버전에있었습니다. 우리는 Spring 3.1.3을 사용하고 있었지만 Spring 3.2 (그들은 Spring 버전의 최근 업그레이드에 대해 끊임없이 말하고있었습니다)을 사용하고 있다고 생각했습니다.

는 설명 내 사냥을 통해 우연히 블로그 게시물이 고정 얻을, 여기이었다 http://blog.springsource.org/2012/11/07/spring-framework-3-2-rc1-new-testing-features/

그리고 관련 부분의 복사 붙여 넣기 :

에서 일반적인 팩토리 메소드의 사용 Spring 설정은> 테스트와 관련이있는 것은 아니지만 EasyMock.createMock (MyService.class) 또는 Mockito.mock (MyService.class)과 같은 일반적인 팩토리 메소드는> 테스트 애플리케이션 컨텍스트에서 스프링 빈에 대한 동적 mock을 생성하는 데 종종 사용된다. . 예를 들어 Spring Framework 3.2 이전 버전에서는 OrderRepository를 OrderService에 autowire하지 못했습니다. 이유는> 빈이 애플리케이션 컨텍스트에서 초기화되는 순서에 따라> Spring은 orderRepository 빈의 유형이 com.example 대신 java.lang.Object>로 추측 될 수 있기 때문입니다.저장소. 주문 보관소.

그렇다면이 문제를 어떻게 해결했을까요?

• 조롱 필요한 테스트에서 새로운 받는다는 모듈을
• 필터를 만들 : 음, 다음 단계를했다. 모든 비 모의 테스트는 Spring 빌드에서 별도의 Failsafe 실행 (기본 패키지 "clean"을 생성하고 그런 식으로 정렬)에서 정상적으로 실행됩니다.
• 모의 테스트를 모두 기본 패키지 "mocked"하고 조롱 한 테스트를 위해 Failsafe에서 추가 실행을합니다.
• 각각의 조롱 된 테스트는 Springockito를 사용하여 mock을 만듭니다. 또한 Springockito 주석을 사용하여 @ReplaceWithMock을 쉽게 수행 할 수 있습니다. 모든 조롱 된 테스트는 @DirtiesContext로 주석 처리되므로, 각 테스트 후에 컨텍스트가 더러워지고 Spring 컨텍스트가 각 테스트와 함께 다시 도입됩니다.

Spring 프레임 워크에서 Spring Bean의 관리를 인계받는 프레임 워크 (Springockito)가 있기 때문에 합리적으로 설명 할 수 있습니다. 그것이 맞는지 나는 모른다. 그러나 그것이 내가 생각할 수있는 가장 좋은 설명이다. 사실, 더티 컨텍스트의 정의입니다. 따라서 더티 컨텍스트로 정의해야합니다.

이 전략을 사용하여 빌드를 다시 실행하고 모든 테스트가 정상적으로 실행됩니다. 완벽하지는 않지만 작동하고 일관성이 있습니다.