테스트 코드에 대한 정리 및 고민 기록

이전에 했던 프로젝트들에 대해선 테스트코드는 작성하지 않았다. 작성했다 해도 왜 테스트코드를 작성하는지도 잘 모르고 대충 끄적여본게 다였다. 

 

tickerBell 프로젝트를 진행하면서 통합테스트, 단위테스트를 진행하며 완성도 높은 프로젝트를 완성해보려 한다.

 

우선 단위테스트에 많이 사용하는 Mock, Mockito에 대해 소개하고자 한다.

 

 

Mock이란?

Mock은 한글로 "모의, 가짜의"라는 뜻으로 테스트할 때 필요한 실제 객체와 동일한 모의 객체를 만들어 테스트의 효용성을 높이기 위해 사용한다. 

 

예제를 보면서 왜 Mock을 사용하는지 알아보자

 

@Service
public class StudyService {
    
    public Student getStudent() {
        // DB에서 study 테이블 조회 (부하가 많이 걸리는 작업)
    }
}

 

위 코드를 테스트한다면 매번 테스트할 때마다 DB를 읽어오게된다. 만약 위 로직이 부하가 많이 걸리고 수행 시간이 오래 걸린다면 테스트 코드를 실행하는데 상당한 시간이 소요된다. 

 

그래서 Student를 DB에서 읽어오지 않고 이를 가짜 객체 즉, mock으로 만들어서 DB에 있는 테이블 접근을 최소화할 수 있다. 

mock 객체를 만들면 테스트 시간을 줄이면서 불필요한 리소스 소비를 막을 수 있다. 

 

또한 인터페이스만 나온 작업에 대해서도 mock 객체를 사용한다면 구현 전에 테스트 코드를 작성할 수 있다.

 

Mockito란?

mock을 쉽게 만들고 mock의 행동을 정하는 stubbing, 정상적으로 작동하는지에 대한 verify 등 다양한 기능을 제공해주는 프레임워크이다.

 

 

@Mock

@Mock으로 만든 mock 객체는 가짜 객체이며 그 안에 메소드 호출해서 사용하려면 반드시 스터빙(stubbing)을 해야한다.

 

 

@Spy

@Spy로 만든 mock 객체는 진짜 객체이며 메소드 실행 시 스터빙을 하지 않으면 기존 객체의 로직을 실행한 값을, 스터빙을 한 경우엔 스터빙 값을 리턴한다.

 

 

@InjectMock

@InjectMock은 DI를 @Mock이나 @Spy로 생성된 mock 객체를 자동으로 주입해주는 어노테이션이다.

 

 

OngoingStubbing 메소드

when에 넣은 메소드의 리턴 값을 정의해주는 메소드이다.

 

when({스터빙할 메소드}).{OngoingStubbing 메소드};

 

 

메소드명	설명
thenReturn	스터빙한 메소드 호출 후 어떤 객체를 리턴할 건지 정의
thenThrow	스터빙한 메소드 호출 후 어떤 Exception을 Throw할 건지 정의
thenCallRealMethod	실제 메소드 호출

 

 

Stubber 메소드

Stubber 메소드는 OngoingStubbing과 다르게 when에 스터빙할 클래스를 넣고 그 후에 메소드를 호출한다. 그 이유는 스터빙이 반드시 실행되야 하는 경우 사용하는 메소드이기 때문이다.

 

{Stubber 메소드}.when({스터빙할 클래스}).{스터빙할 메소드}

 

 

메소드명	설명
doReturn	스터빙 메소드 호출 후 어떤 행동을 할 건지 정의
doThrow	스터빙 메소드 호출 후 어떤 Exception을 throw할  건지 정의
doAnswer	스터빙 메소드 호출 후 작업을 할지 custom하게 정의
doNothing	스터빙 메소드 호출 후 어떤 행동도 하지 않게 정의
doCallRealMethod	실제 메소드 호출

 

 

Verify

verify 메소드를 이용해서 스터빙한 메소드가 실행됐는지, n번 실행됐는지, 실행이 초과되지 않았는지 등 다양하게 검증해볼 수 있다. 

 

verify(T mock, VerificationMode mode).{메소드}

 

 

메소드명	설명 (테스트 내에서~)
times(n)	몇 번이 호출됐는지 검증
never	한 번도 호출되지 않았는지 검증
atLeastOne	최소 한 번은 호출됐는지 검증
atLeast(n)	최소 n 번이 호출됐는지 검증
atMostOnce	최대 한 번이 호출됐는지 검증
atMost(n)	최대 n 번이 호출됐는지 검증
calls(n)	n번이 호출됐는지 검증 (InOrder랑 같이 사용해야 함)
only	해당 검증 메소드만 실행됐는지 검증
timeout(long mills)	n ms 이상 걸리면 Fail 그리고 바로 검증 종료
after(long mills)	n ms 이상 걸리는지 확인 timeout과 다르게 시간이 지나도 바로 검증 종료가 되지 않는다.
description	실패한 경우 나올 문구

 

 

 

 

예외 테스트

예외 발생에 대한 테스트 하는 방법은 여러가지가 있었다. 많이 사용하는 4가지가 있었는데 그 중 가장 가독성이 높고 많이 사용하는 assertj의 assertThatTrownBy를 사용하기로 했다. 예외 테스트 4가지는 아래와 같다.

 

1. assertThrows

2. assertj의 assertThatThrownBy

3. assertEquals (try ~ catch)

4. assertThrows 반환값 사용

 

• 사용 예시

 

assertThatThrownBy(() -> ticketingService.saveTicketing(memberId, request))
                .isInstanceOf(CustomException.class)
                .hasMessageContaining(ErrorCode.SEAT_INFO_NOT_VALID_FORMAT.getErrorMessage());

 

 

 

 

테스트 코드에서 엔티티 @ID 값 Null 이슈

이번 프로젝트에선 엔티티에 setter를 사용하지 않기로 했다. 다양한 이유들이 있지만 해당 게시글은 테스트 관련 게시글이기 때문에 넘어가겠다. 하지만 이렇게 될 경우 테스트코드에서 엔티티를 생성할 때 Id값을 지정해주지 못 해 nullPointException이 터졌다. 

Member member = memberRepository.findByEmail(email);
teamRepository.findTeamByMember(member.getId())

위와 같은 로직의 service를 테스트 한다고 가정하자.

memberRepository의 반환값을 따로 만든 member로 스터빙 해줄 것이다. 하지만 member엔 Id값이 null 이므로 에러가 나게 된다. 

 

teamRepository.findTeamByMember(member.getId())를 스터빙 할 때 인자 값으로 null을 넘겨주면 해결되긴 했지만 좋지 않은 방법 같았다. 

 

고민끝에 Mockito Spy를 사용하기로 했다. 

Mockito의 spy는 기존 객체를 그대로 들고 있으면서 특정 메서드만 스터빙 할 수 있는 객체이다. 

아래와 같이 member의 id값만 스터빙하여 해결할 수 있었다. 

 

Member spyMember = spy(member);
when(spyMember.getId()).thenReturn(1L);

 

 

 

 

Querydsl 사용 시 DataJpaTest 실패

프로젝트에서 querydsl 을 설정을 해주고 test case 을 작성하였다. 하지만 jpaqueryfactory 가 bean 주입을 받지 못하면서 에러가 발생이 되었다. 에러는 아래와 같다.

 

No qualifying bean of type 'com.querydsl.jpa.impl.JPAQueryFactory' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

 

TestConfig 클래스를 따로 만들어 해결해주었다. 

@TestConfiguration : test case 작정시 설정을 주입 시켜주는 어노테이션 

@PersistenceContext : 이 어노테이션을 통해서 EntityManager 영속성을 주입시켜줌.

 

@TestConfiguration
public class TestConfig {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory(){
        return new JPAQueryFactory(entityManager);
    }

}

 

 

만든 TestConfig는 테스트 코드에서 @Import 해서 사용할 수 있다. 

 

 

 

 

 

 

Spring Security 사용 시 통합 테스트 코드에서의 인증, 인가

컨트롤러 테스트를 하기 위해 통합테스트 작성중에 시큐리티를 사용한 코드가 있어 에러가 터졌다. 

 

exception: java.lang.NullPointerException: Cannot invoke "com.tickerBell.global.security.context.MemberContext.getMember()" because "memberContext" is null

 

 

컨트롤러 코드의 일부이다. 

 

 

컨트롤러 코드에서 @AuthenticationPrincipal 을 사용해 현재 로그인 한 사용자 정보를 가져오는데 이때 null 값이 들어오게 되고 null 에 접근하는 코드에서 NullPointerException이 터진 것이다. 

그렇다고 SpringSecurity를 통해서 접근제어를 해놓은 URL로 Controller Test를 할 때 매번 인증로직(로그인, 토큰..)을 붙여주는건 효율이 매우 떨어졌다. 

이때 @withUserDetails활용하면 Test에서 header에 token을 넣어주지 않아도  간편하게 테스트 할 수 있다.

 

@WithUserDetails

 

@withUserDetails는 UserDetailsService를 통해서 User객체를 직접 반환하기 때문에 나처럼 객체가 직접 필요할 때는 이 방법을 쓰는게 좋은 것 같다. 

 

value는 어떤 username을 갖은 user를 SecurityContextHolder에 넣을지 userDetailsServiceBeanName은 어떤 UserDetailsService를 이용할지 알려주는 것이다. 만약 Custom을 했다면 그것을 적어주면된다. 나는 따로 커스텀하지 않았기 때문에 따로 적어주지 않았다.

 

하지만 이때 value는 실제로 해당 username을 가진 user가 존재해야한다.

따라서 Test진행전에 user객체를 넣어놔야하기때문에 @BeforeEach를 통해서 user를 저장해놓으면 된다.

 

 

또 다른 이슈! 

SecurityContext는 default로 TestExecutionListener.beforeTestMethod로 설정이 되어있다.

즉 @Before 전에 @withUserDetails이 동작해서 SecurityContext안에 넣으려고한다.

따라서 실 user객체가 생기기전에 해당 user를 찾게 되고 실패하게 된다.

해결법으로 아래 옵션을 추가해주면 된다.

 

setupBefore = TestExecutionEvent.TEST_EXECUTION)