스프링 테스트 - Githubissues

스프링 테스트 (Spring Test)

스프링프레임워크에서 동작하도록 만든 클래스 (@Controller, @Service, @Repository, @Component 등이 붙은 클래스 )를 테스트 하는 모듈

개발한 클래스는 크게 단위 테스트와 통합 테스트로 나눠서 테스트하는 것이 일반적

단위 테스트

테스트할 클래스의 구현 내용만 테스트함

테스트할 클래스가 의존하는 다른 컴포넌트를 목(mock)이나 스텁(stub)으로 만들어, 테스트 대상 클래스의 실행 결과가 다른 컴포넌트의 실행 내용에 좌우되지 않게 함

통합 테스트

목이나 스텁은 사용하지 않고, 실제 운영 환경에서 사용될 클래스를 통합해서 테스트함

스프링 테스트를 활용한 통합테스트는 시스템이나 애플리케이션 전체가 의도한대로 정확하게 동작하는지를 검증하는 것이 아닌, 개발자가 작성한 클래스가 스프링프레임워크에서 정확하게 동작하는지 검증하는 테스트임

DI 컨테이너에서 관리되는 빈(@Controller, @Service, @Repository, @Component 등이 붙은 클래스)을 테스트하는 방법

빈에 대한 단위테스트

스프링의 DI 컨테이너 기능을 사용하지 않고, 테스트 대상 클래스에서 구현한 로직만 테스트)
ex) 외부참조 없이 하드코딩된 고정 메시지를 반환하는 클래스를 JUnit으로 테스트 할때 사용

// 고정메시지를 반환하는 클래스
@Service
public class MessageService {
   public String getMessage() { regurn "Hello!!"; }
}

// 고정 메시지를 반환하는 클래스의 JUni 테스트 케이스
public class MessageServiceTest {
   @Test
   public void testGetMessage() {
      MessageService service = new MessageService();
      String actualMessage = service.getMessage();
      assertThat(actualMessage, is("Hello!!"));
   }
}

스프링이 제공하는 MessageSource 인터페이스를 이용해 외부에서 메시지를 가져오는 구현클래스를 테스트 하는 방법
- 실제 운영환경이라면 MessageSource에 ResourceBundleMessageSource를 사용해 외부에 정의된 메시지를 가져오는 것이 정상
- 단, 단위테스트 환경에서는 의존컴포넌트인 MessageSource를 모의화(Mocked)해서 테스트를 할 수 있음
- 의존 컴포넌트를 모의화하면 테스트 조건을 쉽게 만들 수 있어 테스트 코드를 효율적으로 기술 할 수 있게 도와줌
- 의존 컴포넌트의 반환값에 따라 복잡한 분기처리를 하는 경우에는 의존 컴포넌트에서 반환값을 자유롭게 제어할 수 있는 목 구조가 상당히 유용함
```
// MessageSource에서 메시지 취득하는 클래스
@Service
public class MessageService {
@Autowired
MessageSource messageSource;
```
public String getMessageByCode( String code ) { return messageSorce.getMessage(code, null, Locale.getDefault( ) ); }

}


```java
// MessageSource에서 메시지를 가져오는 클래스의 JUnit테스트 케이스
// Mockito를 사용해 MessageSource를 모의화한 테스트 케이스
@RunWith(MockitoJUnitRunner.class)
public class MessageServiceTest { 
   // MockitoJUnitRunner를 이용해 테스트할 컴포넌트(@InjectMocks를 부여한 컴포넌트)에 모의화한 컴포넌트(@Mock이나 @Spy를 붙인 컴포넌트)를 인젝션 할 수 있게 함
   @InjectMocks
   MessageService service;

   @Mock
   MessageSource mockMessageSource;

   @Test
   public void testGetMessageByCode() {
      doReturn("Hello!!").when(mockMessageSource).getMessage("greeting",null, Locale.getDefault());
      // MessageSource의 목을 설정했음. 'greeting'이라는 코드가 지정될때 'Hello!!'가 반환하게 함
      String actualMessage = service.getMessageByCode("greeting");
      assertThat(actualMessage, is("Hello!!"));
   }
}

DI 컨테이너에서 관리된느 빈에 대한 통합 테스트

단위 테스트 통과한 클래스는 스프링의 DI 컨테이너에 등록된 후 다른 컴포넌트까지 통합된 상태에서 테스트를 더 해야 함

기본적으로 DB와 같은 외부 리소스의 접근까지 포함해서 테스트하는 것이 바람직한 통합 테스트이지만 각종 제약으로 인해 완벽한 조건에서 테스트 하기 어려움

편의상 외부시스템이나 외부 사이트와 연계되는 부분을 목(Mock)이나 스텁(Stub)으로 대체 해도 됨

(1) 빈 정의 파일 작성

DI 컨테이너를 생성할때 사용할 빈 정의 파일을 만든다

빈 정의 파일에는 MessageService클래스를 컴포넌트 스캔하기 위한 설정을 해야 하고, MessageService 클래스가 의존하는 MessageSource의 빈도 정의해야 함

// 자바 기반 설정 방식을 이용한 빈 정의 @Configuration @ComponentScan("com.exaple.domain") // 컴포넌트 스캔을 활성화 public class AppConfig { @Bean // MessageSource의 빈정의 public MessageSource messageSource() { ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource(); messageSource.setBasenames("messages"); return messageSource; } }

ResourceBundleMessageSource가 읽어들일 프로퍼티파일(messages.properties)은 클래스패스 바로 아래에 생성함

// message.properties 정의 예시
greeting=Hello!!

(2) 테스트 케이스 작성과 실행

@RunWith의 value속성에 JUnit에서 테스트용 DI컨테이너 동작시키기 위한 Runner클래스 지정

@ContextConfiguration의 classes 속성에 DI컨테이너가 사용하는 설정 클래스 지정

@Autowired를 사용해 DI 컨테이너에 등록할 테스트 대상 빈을 인젝션함

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(classes=AppConfig.class) // 
public class MessageServiceIntegrationTest {
@Autowired
MessageService service;

@Test
public void testGetMessageByCode( ) {
  String actualMessage = service.getMessageByCode("greeting");
  // 인젝션된 빈의 메서드를 호출해서 DI컨테이너에 의해 의존 관계가 결합된 컴포넌트를 테스트함
  assertThat(actualMessage, is("Hello!!");
}
}

테스트 케이스를 실행했을때 클래스패스 상의 message.properties에서 메시지 "Hello!!"를 가져왔다면 테스트 성공

정말 프로퍼티 파일에서 가져온 것인지 확인하고 싶다면 message.properties의 메시지 정의를 greeting=Bonjour!!로 바꿔서 다시 테스트해보면 실패하는 것을 통해 제대로 컴포넌트가 통합된 것을 재확인 가능

berryberrybin / board-project

스프링 테스트 #8