📖미션

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.

2. 아래 3개의 테스트가 있습니다.
내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요?
(@BeforeEach에 올라간 내용은 공통 항목으로 합칠 수 있습니다. ex. 1-1과 2-1을 하나로 합쳐서 @BeforeEach에 배치)

📄첫 번째 미션

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.

차이점

@Mock

@Mock
private MailSendClient mailSendClient;

완전한 가짜 객체로 만듭니다.

동작을 정의해놓은 메서드만 수행됩니다.

@Spy

@Spy
private MailSendHistoryRepository mailSendHistoryRepository;

실제 객체를 한 번 감싸서 가짜 객체로 만듭니다.

동작을 정의해놓은 메서드는 정의대로 수행되지만

그렇지 않은 메서드는 실제 객체의 행동을 수행합니다.

@InjectMocks

@Mock
private MailSendClient mailSendClient;

@Spy
private MailSendHistoryRepository mailSendHistoryRepository;

@InjectMocks
private MailService mailService;

@Mock이나 @Spy로 가짜 객체를 만들었다면

이 가짜 객체를 필드에 주입해 줄 수 있습니다.

예를 들어,

C c = new C(A, B)인데

A와 B를 가짜 객체로 만들었다면

C에 @InjectMocks를 붙여서 A와 B를 필드로 갖는 가짜 객체를 만들 수 있습니다.

@MockBean

@MockitoBean
private OrderService orderService;

기존에 스프링 컨테이너에 등록되어 있던 빈을

가짜 빈으로 바꿔줍니다.

예를 들어, OrderRepository가 실제 빈으로 등록되어있었다면

@SpringBootTest에선 가짜 OrderRepoistory 빈으로 바꿔치기 해주는 식

@SpyBean

@MockitoSpyBean
private ProductService productService;

마찬가지로 스프링 컨테이너에 등록되어 있는 빈을

가짠 빈으로 바꿔줍니다.

이 때, 실제 빈을 한 번 감싸서 가짜 빈을 만들어줍니다.

Spring Boot 3.4 부터 @MockBean과 @SpyBean이 deprecated 처리되었으며

Spring Boot 4.0부터 삭제 될 예정이라고 합니다.

대신 @MockitoBean과 @MockitoSpyBean을 사용하라고 명시되어있습니다. 🫡 

🔗spring.io 문서 참고

📄두 번째 미션

아래 3개의 테스트가 있습니다.
내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요?
(@BeforeEach에 올라간 내용은 공통 항목으로 합칠 수 있습니다. ex. 1-1과 2-1을 하나로 합쳐서 @BeforeEach에 배치)

중복 제거를 우선 시 할 경우

@BeforeEach 
void setUp() {
    1-1. 사용자 생성에 필요한 내용 준비
    1-2. 사용자 생성
}

@DisplayName("사용자가 댓글을 작성할 수 있다.")
@Test
void writeComment() {
    // given
    1-3. 게시물 생성에 필요한 내용 준비
    1-4. 게시물 생성

    1-5. 댓글 생성에 필요한 내용 준비

    // when
    1-6. 댓글 생성    

    // then
    검증
}

@DisplayName("사용자가 댓글을 수정할 수 있다.")
@Test
void updateComment() {
    // given
    2-3. 게시물 생성에 필요한 내용 준비
    2-4. 게시물 생성

    2-5. 댓글 생성에 필요한 내용 준비
    2-6. 댓글 생성

    // when
    2-7. 댓글 수정

    // then
    검증
}

@DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.")
@Test
void cannotUpdateCommentWhenUserIsNotWriter() {
    // given
    3-3. 사용자2 생성에 필요한 내용 준비
    3-4. 사용자2 생성

    3-5. 사용자1의 게시물 생성에 필요한 내용 준비
    3-6. 사용자1의 게시물 생성

    3-7. 사용자1의 댓글 생성에 필요한 내용 준비
    3-8. 사용자1의 댓글 생성

     // when
    3-9. 사용자2가 사용자1의 댓글 수정 시도

     // then
    검증 
}

가독성을 우선 시 할 경우

@BeforeEach 
void setUp() {

}

@DisplayName("사용자가 댓글을 작성할 수 있다.")
@Test
void writeComment() {
    // given
    1-1. 사용자 생성에 필요한 내용 준비
    1-2. 사용자 생성

    1-3. 게시물 생성에 필요한 내용 준비
    1-4. 게시물 생성

    1-5. 댓글 생성에 필요한 내용 준비

    // when
    1-6. 댓글 생성    

    // then
    검증
}

@DisplayName("사용자가 댓글을 수정할 수 있다.")
@Test
void updateComment() {
    // given
    2-1. 사용자 생성에 필요한 내용 준비
    2-2. 사용자 생성

    2-3. 게시물 생성에 필요한 내용 준비
    2-4. 게시물 생성

    2-5. 댓글 생성에 필요한 내용 준비
    2-6. 댓글 생성

    // when
    2-7. 댓글 수정

    // then
    검증
}

@DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.")
@Test
void cannotUpdateCommentWhenUserIsNotWriter() {
    // given
    3-1. 사용자 생성에 필요한 내용 준비
    3-2. 사용자 생성

    3-3. 사용자2 생성에 필요한 내용 준비
    3-4. 사용자2 생성

    3-5. 사용자1의 게시물 생성에 필요한 내용 준비
    3-6. 사용자1의 게시물 생성

    3-7. 사용자1의 댓글 생성에 필요한 내용 준비
    3-8. 사용자1의 댓글 생성

     // when
    3-9. 사용자2가 사용자1의 댓글 수정 시도

     // then
    검증 
}

미션 후기

@Mock과 @Spy의 차이점에 대해 더 상세히 인지할 수 있었습니다.

가독성과 코드 중복 제거 관점에서 setUp을 사용하는 게 좋을 지 아닐지 고민할 수 있었습니다.

읽어주셔서 감사합니다. 🙂‍↕

강의

🔗Practical Testing: 실용적인 테스트 가이드