Service - 책 등록하기 테스트

본 시리즈는 메타 코딩님의 Junit 강의를 학습한 내용을 바탕으로 정리하였습니다.

서비스 기능을 모두 구현했다. 이제는 테스트를 안하는게 더 어색하다. 실제로 DB를 통해 테스트해보자.

test 디렉토리 하위에 service 폴더 밑에 BookServiceTest.java 를 생성한다.

책 등록하기_테스트( )

BookServiceTest

package site.metacoding.junitproject.service;

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;

import site.metacoding.junitproject.domain.BookRepository;
import site.metacoding.junitproject.util.MailSenderStub;
import site.metacoding.junitproject.web.dto.BookRespDto;
import site.metacoding.junitproject.web.dto.BookSaveReqDto;

@DataJpaTest
public class BookServiceTest {

    @Autowired
    private BookRepository bookRepository;

    @Test
    public void 책등록하기_테스트() {
        // given	//  1.
        BookSaveReqDto dto = new BookSaveReqDto();
        dto.setTitle("Junit강의");
        dto.setAuthor("메타코딩");

        // stub (가짜)
        MailSenderStub mailSenderStub = new MailSenderStub();
        //  2.

        // when
        BookService bookService = new BookService(bookRepository, mailSenderStub);
        BookRespDto bookRespDto = bookService.책등록하기(dto);
        //  3. 

        // then
        assertEquals(dto.getTitle(), bookRespDto.getTitle());
        assertEquals(dto.getAuthor(), bookRespDto.getAuthor());
        //  4.
    }
    
}

1. 책을 등록하기 위해 BookSaveReqDto 를 dto 로 생성한다.
2. 가짜로 BookRepository 를 가져오기 위해 mailSenderStub 을 new 로 생성한다.
3. new 로 호출된 BookService 가 실제 BookRepository 에 저장하기 위한 책 등록하기 메소드를 실행한다.
4. dto 에 들어가는 예상값과 실제 bookRespDto 에 들어가는 Title, Author 가 일치하는지 assertEquals 로 검증한다.

이제 실제 테스트를 돌려보자.

테스트가 잘 통과된 것을 볼 수 있다.

그런데... 🤔

한 가지 개선했으면 하는 부분이 있다. 우리는 현재 우리가 만든 Service 레이어만 테스트를 하고 싶은데 Repository 레이어가 함께 DI되고 테스트 된다는 것이다.

Service 레이어가 Repository 레이어에 의존하고 있기 때문에 이미 Repository 의 테스트를 끝냈음에도 불구하고 같이 테스트가 되는 것인데 물론 이런식으로 테스트를 해도 문제가 될 것은 없다. 그렇지만 테스트가 무거워지고 비효율적임에는 틀림없다.

Service 레이어만 따로 테스트할 수 있는 방법이 없을까?

가짜 환경 테스트

가짜 메일을 만들었던 것처럼 가짜 환경을 구축하고 가짜 Repository 를 띄운다면 이 이슈를 해결할 수 있을 것이다.

즉, 가짜가 진짜를 대신하고 우리가 이를 가지고 논다면 굳이 실제 Repository 를 메모리에 로드할 필요가 없어진다.

이 것을 구현하기 위해 Mockito 라는 프레임워크가 필요하다.

Mockito 란❓
Mock 객체를 쉽게 만들고 관리하고 검증할 수 있는 방법을 제공하는 Mock 프레임워크. 여기서 Mock이란 진짜 객체와 비슷하게 동작하지만 프로그래머가 직접 그 객체의 행동을 관리하는 객체를 의미한다.
(출처 : https://velog.io/@znftm97/Mockito-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B01)

쉽게 말해 가짜 객체를 보관하고 관리할 수 있는 환경인 셈이다. 이를 반영해서 코드를 다시 수정해보자. (다음 포스팅에서...)