🐳코프링에 테스트코드를 도입하다.

이번에 테스트 코드에 중요성에 대해 인지하게 되어서 회사 프로젝트에 테스트 코드를 도입해보았다. Junit5를 사용하였고 단위 테스트 보다는 우선 통합 테스트를 먼저 구현하여 보았다. 해당 글에서는 통합 테스트 환경 구축을 위한 정보를 다루고 있습니다.

테스트 코드적용하기 전에 우선 테스트를 쉽게 도와줄 클래스를 먼저 만들어 보았다.

우선 해당 코드를 보기전에 해당 클래스의 목적을 알아보겠다. 해당 클래스의 목적은 크게 2가지가 존재한다.

1. mockMvc를 생성하여 api 테스트

여기서 mockmvc란?

공식 문서에 보면 아래와 같이 설명되어있다.

Main entry point for server-side Spring MVC test support.

해석하면 다음과 같은 뜻이 된다.

서버측 Spring MVC 테스트 지원을 위한 주요 진입점

공식 문서

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/web/servlet/MockMvc.html

그래서 mockmvc의 역할은?

테스트코드를 작성하기 이전에는 코드를 작성한 후 postman을 통하여 직접 해당 api를 호출하여 원하는 값이 나타나는지 확인하였다. 이러한 postman과 같은 역할을 할 수 있는 것이 mockMvc라고 볼 수 있다. http method중 get을 사용할지 post를 사용할지 선택하고 url을 입력하고 필요시 바디나 query string을 통해 인자를 넘겨줄 수 있다. 그리고 해당 결과가 원하는 결과를 얻을 수 있는지 확인할 수 있다.

어떻게 사용할 것인가?

@SpringBootTest
@AutoConfigureMockMvc

mockmvc를 사용하기 위해서 위 어노테이션을 활용하였다.

@SpringBootTest 어노테이션이란 ?

Spring Boot 기반 테스트를 실행하는 테스트 클래스에 지정할 수 있는 어노테이션이다.

위 어노테이션을 통해서 실제 spring boot가 실행될 때 등록되는 bean들이 실제 환경에서 돌아가듯 스프링 컨테이너 위로 모두 올라가 테스트를 하게 된다.

장점

• 실제와 같은 환경에서 테스트할 수 있다.
• 전체적인 flow를 테스트할 수 있다.

단점

• 애플리케이션의 설정과 등록된 모든 Bean들을 로드하기 때문에 시간이 오래걸린다. 이러한 단점 덕분에 대량의 테스트를 하는 곳에서는 다른 방식으로 테스트 한다고 들었다.

@AutoConfigureMockMvc이란?

MockMvc의 자동 구성을 활성화하고 구성하기 위해 테스트 클래스에 적용할 수 있는 주석

mockMvc를 사용할 때 속도를 높이기 위해서 특정 클래스를 지정하여서 해당 부분만 로드하는 방식도 있지만 해당 방식으로 진행해보다 빈 등록 문제 때문에 위의 어노테이션을 활용하여 보았다. 쉽게말해 mockMvc의 구성을 자동으로 활성화 해주는 어노테이션이다.

어노테이션에 관한 설명 참조

https://goddaehee.tistory.com/211

그리고 어노테이션 설정과 mockMvc사용을 위한 추가적인 설정을 아래와 같이 진행하였다.

fun applyEncodingFilter() {
    this.mockMvc = MockMvcBuilders
        .webAppContextSetup(this.ctx)
        .apply<DefaultMockMvcBuilder>(springSecurity())
        .addFilters<DefaultMockMvcBuilder>(
            CharacterEncodingFilter("UTF-8", true),
        ).build()

}

@BeforeEach
fun setUp() {
    applyEncodingFilter()
}

매번 요청할 때마다 위와같이 mockMvc를 초기화 하며 대표적으로 springSecurity 설정과 UTF-8 인코딩 설정을 진행하고 있다. 위와같이 초기화 하지않고 그냥 mockMvc 생성 위애 @Autowire를 붙이고 실행하여 보았는데 나중에 통합 테스트를 진행할 때 테스트 끼리 충돌하여 실패하는 케이스가 발생하여 위와같이 매번 초기화 하는 방식으로 진행하였다.

2. 권한이 필요한 API 테스트를 위해서 mock 유저 생성

테스트가 간단하게 되면 좋겠지만 권한이 필요한 API 같은 경우 간단하게 되지 않는다. 그래서 mock 유저 주입을 위한 설정이 필요하다. mock이라는 단어를 사용한 이유는 단어 뜻 그대로 권한이 필요할 경우만 사용하는 임시 유저이기 때문이다.

mock 유저를 생성하기위해서 memberRepo와 passwordEncoder의 의존성을 주입 받는다.

@Autowired
lateinit var memberRepo: MemberRepo

@Autowired
lateinit var passwordEncoder: PasswordEncoder

passwordEncoder는 왜 사용하는지 의문이 들 수 있다. passwordEncoder를 사용한 이유는 유저 정보를 db에 저장할 때는 비밀번호를 암호화 하여서 저장하여야 되기 때문이다.

유저를 생성하기 위해서 @BeforeTransaction 어노테이션과 @AfterTransaction 어노테이션을 활용하였다. 활용한 테스트 메소드 이전에 유저가 생성되어야되기 때문이다.

@BeforeTransaction 의 공식 설명

@Transactional 주석을 통해 트랜잭션 내에서 실행되도록 구성된 테스트 메소드에 대해 트랜잭션이 시작되기 전에 주석이 달린 공용 void 메소드가 실행되어야 함을 나타내는 테스트 주석. 슈퍼클래스의 @BeforeTransaction 메서드는 현재 클래스의 메서드보다 먼저 실행됩니다.

@BeforeTransaction
fun setUpAccount() {
    val member = Member(
        email = "test@naver.com",
        password = passwordEncoder.encode("password"),
        nickname = "nicktest",
        username = "username",
        birthDate = LocalDate.now(),
        phone = "01012345678",
        phoneKey = "ewuifhiwefheih2423r",
        agePolicyConsent = true,
        servicePolicyConsent = true,
        personalInfoPolicyConsent = true,
        smsConsent = false,
        emailConsent = false
    )
    member.updateRole(Role.ADMIN)
    testMember = memberRepo.save(member)
}

@AfterTransaction
fun cleanUpAccount() {
    val member = memberRepo.findByEmail("test@naver.com")
    member?.let{memberRepo.delete(it)}
}

beforeTransaction 어노테이션의 이름과 같이 transaction을 걸어줘야지 해당 메소드 이전에 실행된다.

그리고 위와같이 생성한 유저 를 사용하기 위해서 아래와 같이 WithUserDetails 어노테이션을 활용할 수 있다.

@WithUserDetails(testUser)

참조 블로그

https://freedeveloper.tistory.com/471