TDD 실천하기

- JUNIT TEST

리펙토링을 하는데 있어서 테스트가 필수!(리펙토링을 하기 위한 전제조건!)

- How to test?

mockito를 이용 해보자.

설정을 해보자. 현재 maven을 사용.

위의 그림처럼 maven dependency를 설정(pom.xml)하여 준다.(mockito라는것을 사용해보려고 한다.)

현재(2015년11월의 최신 릴리즈버전이다.)

<dependency>

    <groupId>org.mockito</groupId>

    <artifactId>mockito-core</artifactId>

    <version>1.10.19</version>

</dependency>

소스에서는 import static org.mockito.Mockito.*; 를 static으로 import 시킨 뒤!

상황에 맞게 테스트 코드를 만들어서 사용하시면 됩니다.

참고 url : https://code.google.com/p/mockito/wiki/MockitoFeaturesInKorean

- TDD를 하는데 있어서 가장 어려운 것은 무엇일까? 특히나 as-is소스에 대한 테스트 코드를 짜려고하는데 왜이렇게 힘든걸까?

BDD의 given / when / then의 패턴을 따른다고 가정하면..

1. 테스트 범위 선정에 대한 어려움.

2. 테스트를 해야하는지에 대한 여부 판단.

3. 다른 객체들과의 참조일 때의 처리 방법.(mockito의 사용법을 잘 모르는 상태)

4. BDD에서 말하는 given / when / then의 패턴과 mockito의 문법과 헷깔림. how to use??

---

TDD 실천하기 Step 01.

 - 선정해보자. TDD를 하기 위한 소스!

 - mockito 익히기!

 - TDD 소스 짜보기(given / when / then 형태)

** 선정 기준 **

우선은 리턴이 있는 친구로!

ex) 

test  할 소스( 조금 애매할 수 있는 소스..ㅋㅋ)

public accountResultDto getAccount(AccountInfo accountInfo){

   AccountResultDto  accountResultDto = accountRepository.getAccount(accountInfo.getAccountSeq);

   if(accountResultDto == null) return null;

   accountResultDto.setXXX(accountInfo);

   return accountResultDto;

}

-- TEST Code --

// given

제공해야하는 객체 또는 파라미터들에 대한 셋팅을 해준다.

accountResultDto와 accountInfo가 되겠다.

// when

mock객체(Repository같은 database와 연결되어지는 것 들)

실제로 테스트할 메소드 호출을 하는 부분이다. 

// then

그 결과를 assertThat 등으로 체킹한다.

아래의 소스를 보고 더 파악을 해보자.

import org.junit.Test;

import org.junit.runner.RunWith;

import org.mockito.InjectMocks;

import org.mockito.Mock;

import org.mockito.runners.MockitoJUnitRunner;

import static org.hamcrest.CoreMatchers.*;

import static org.hamcrest.MatcherAssert.assertThat;

import static org.mockito.Mockito.*;

@RunWith(MockitoJUnitRunner.class)

public class AccountTest {

  @InjectMocks Account account;

  @Mock AccountRepository accountRepository;

  @Test

  public void testgetAccountInfo(){

    //given

    Long accountSeq=2224L, dirSeq=1234L, userSeq=5678L;

    AccountInfo accountInfo = new AccountInfo();

    accountInfo.setAccountSeq(accountSeq);

    accountInfo.setDirSeq(dirSeq);

    accountInfo.setSiteUserSeq(userSeq);

    

    AccountResultDto accountResultDto = new AaccountResultDto();

    // when

    when(accountRepository.getAccount(accountSeq)).thenReturn(accountResultDto);

    account.getAccountInfo(accountInfo);

    // then

    assertThat(accountResultDto.getAccount_seq(), is(2224L));

    assertThat(accountResultDto.getDir_seq(), is(1234L));

    assertThat(accountResultDto.getAccount_user_seq(), is(5678L));

  }

위의 소스에서와 같이 BDD의 given / when / then 방식으로 코딩을 하였고 중요하게 보아야할 것은 @InjectMocks와 @Mock 어노테이션을 통해 쉽게 DI를 해주었다는 부분과 아래의 소스 부분이다.

  1)  when(accountRepository.getAccount(accountSeq)).thenReturn(accountResultDto);

  2) account.getAccountInfo(accountInfo);

1) 부분이 Mock을 처리한 부분이고 2)가 테스트 대상을 호출하였다.(DI는 @InjectMocks)

호출을 하게 되면 소스상에서 Mock으로 선언된 accountRepository를 만나게 되면 when구문이 발동되어 우리가 예상했던 Return값을 받게 된다.(accountResultDto) 즉, 아래에서 우리가 테스트를 할 녀석은 b) 인 것이다.

   a) if(accountResultDto == null) return null;

   b) accountResultDto.setXXX(accountInfo);

그리고나서 assertThat등으로 확인을 하면 된다.

#참고 : given에서 넘겨줄 데이터를 채워서 보내주는데 이러한 부분을 '픽스처' 라는 용어를 사용하기도 한다.

픽스처를 다양하게 만들어서 필요한 테스트 코드를 만들면 된다.

그러나 보통 픽스처가 덩치가 크거나 공통적으로 사용되는 부분이 있어서 많아지게 되면 관리의 어려움이 있다.

이것에 대한 해결책은 한번 찾아보고 생각해봐야할 것이다.

일단은.. 끝~