2023/01/05 TIL | Mockito, TDD

💭 오늘의 학습 전략

# Mockito

◼️ Mock

◼️ Mockito

　◽Mockito 실습

# TDD(Test Driven Development)

◼️ 특징

◼️ 장단점

🌼 학습한 것들

◾ Mock

　▪️ Mock: 진짜와 유사한 상황, 물건, 물질

　▪️ 테스트에서의 Mock: 가짜 객체

　▪️ 테스트에 Mock을 사용하는 것: Mocking

◾ Mock

　▪️ Mockito: Spring Framework 자체적으로도 지원하는 Mocking 라이브러리

　　==> Mock을 통해 다른 계층과 연결을 분리시켜 테스트 대상에 집중!

◾ Mockito

1) API 계층 슬라이스 테스트

　▪️ @MockBean: Mock 객체 생성 및 주입

　▪️ given:

Mock 객체가 특정 값을 리턴하는 동작 지정

　　- ex) Member 타입의 파라미터를 받아 Member 타입을 반환하는 Mock Service 객체를 정의해두기

    given(memberService.createMember(Mockito.any(Member.class))).willReturn(new Member());

　　=> 이전과 같이 Contoller 테스트 시, 실제 Service가 아닌 Mock 객체를 통해 테스트 진행

　▪️ Stubbing: 테스트를 위해 Mock 객체가 항상 일정한 동작을 하도록 지정하는 것

　　- given -> stubbing method

2) 데이터 액세스 계층 슬라이스 테스트

　▪️ @ExtendWith(MockitoExtension.class): Spring 의존 없이 Junit, Mockito의 기능만 사용

　▪️ @Mock: 해당 필드 객체를 Mock 객체로 생성

　▪️ @InjectMocks: @Mock으로 생성한 객체를 주입해줄 객체

　　- ex) Repository에 의존하는 Service에 주입

    @Mock
    private MemberRepository memberRepository;
    @InjectMocks
    private MemberService memberService;

◾ TDD: 테스트 주도 개발 (테스트 -> 구현)

　▪️ 전통적 개발의 경우

　　- 도메인 도출 -> 백엔드 전반 클래스, 인터페이스 설계 -> 큰 틀 -> 메서드 정의, 구현 -> 테스트 -> 디버깅

　▪️ 특징

　　- 모든 조건을 만족하는 테스트를 먼저 진행 하고, 점진적으로 실패하는 테스트를 하나씩 고쳐간다

　　- 매번 조건에 맞는 테스트가 passed 될 정도씩만 우선 작성하면서 진행

　　- 테스트 실패 -> 성공할만큼 구현 -> 성공 -> 리팩토링 -> 테스트 확인 ...

　▪️ 장점

　　- 테스트 통과할 만큼씩만 구현하기 때문에 한 번에 많이 구현하지 않아도 됨

　　- 단순 기능 -> 복잡 확장 => 그때 그때 검증 -> 그때 그때 리팩토링 => 유지보수 비용 감소

　　- 잘못된 코드가 남아있을 가능성, 심리적 불안감 감소(ㅎㅎ)

　▪️ 단점

　　- 테스트 코드에 익숙하지 않거나 작성하기 싫은 사람에게는 부정적 -> 사전 협의 필요

🔥 보충이 필요한 것들

◾Page 객체 생성

◾과제 완성하기

 

 

💨 하루를 마치며

1. 실습 후기

처음에는 실습을 하나도 진행하지 못 했다. Mockito가 너무 생소하고 흐름이 잘 이해가 되지 않았기 때문이다. 

특히 mapper를 mocking해서 왜 굳이 빈 객체를 리턴하는지,

service mock에서 빈 객체를 리턴하는데 어떻게 테스트 검증이 가능한 건지 등등 아주 아주 혼란스러웠는데

페어분이 잘 설명해주시고 체크포인트 세션까지 들으면서 제대로 이해할 수 있었다!

API 계층 테스트로 살펴보면

controller는 실제 흐름대로 타기 때문에 그 안에서 연결된 리턴값 을 사용하는 로직이 있다면 의미없는 데이터라도 넣어주어야 한다.

service에서 빈 객체를 리턴하더라도 실제 응답에는 아무 연관이 없다. (내가 비즈니스 로직에 자꾸 집착했던 것 같다)

"슬라이스 테스트"의 목적이 진짜 무엇인지 잊고 있었다. 컨트롤러에서의 요청과 응답 처리만 잘 봐주면 된다.

+ mapper는 성능을 고려해서 mocking 여부를 결정하면 된다 (N+1, DB 접근이 계속...) 

fetch default @xxToOne에서는 EAGER, @xxToMany에서는 LAZY