🌈 [Section3] 11. [ Spring MVC ] 테스팅 2

📕 오늘 배운 내용!

• Mockito를 사용한 테스팅 방법

---

✏️ Mock

• not real, but intended to be very similar to a real situation, substance etc
  ( 말 그대로, 진짜는 아니지만 진짜와 아주 비슷한 가짜)

✔️ 목업 (Mock-up)

• 실제 제품이 나오기 전에 내부적으로 사용하기 위한 모형(가짜) 제품
• 테스트 세계에서는 가짜 객체를 의미

---

✔️ Mocking

• 단위 테스트나 슬라이스 테스트 등에 Mock 객체를 사용하는 것

---

✔ 테스트에서 Mock 객체를 사용하는 이유

Mock 객체를 사용하지 않고 MemberController 테스트 중 postMember 테스트를 진행한다고 하면,

 이의 흐름은 아래와 같을 것임 ⬇️

1. MemberControllerTest 클래스 내의 postMemberTest()
2. MemberController 클래스 내의 postMember()
3. MemberService 클래스 내의 createMember()
4. MemberRepository 인터페이스 내의 save()
5. H2
6. 다시 반대로 쭉 돌아가서 테스트 케이스에 도달

But, 이는 거의 모든 계층을 돌고 오기 때문에 완전한 슬라이스 테스트가 아닌, 통합테스트에 가까움

➜ ❗ Mock 객체를 사용하여 다른 계층과 단절을 시켜주어
이 과정을 줄여주고 슬라이스 테스트를 적용할 수 있도록 할 것 !

• Mock 객체를 사용한 MemberController 테스트 중 postMember 테스트의 진행 흐름은
  
  
  1. MemberControllerTest 클래스 내의 postMemberTest()
  2. MemberController 클래스 내의 postMember()
  3. MockMemberService 클래스 내의 createMember()
  4. 다시 반대로 쭉 돌아가서 테스트 케이스에 도달

---

✏️ Mockito

• Mock 객체를 생성하고 해당 Mock 객체가 진짜처럼 동작하게 하는 기능을 하는 Mocking framework(또는 라이브러리)
• Mockito의 Mocking 기능을 이용해서 테스트하고자 하는 대상에서 다른 영역(다른 계층 또는 외부 통신이 필요한 서비스 등)을 단절시켜 오로지 테스트 대상에만 집중할 수 있게 함

[참고 1], [참고 2]
[Mockito 메서드들 참고], [Mockito 지원 Matchers 참고]

---

✔ Mockito 지원 Stubbing 메서드

• given(Mock 객체 클래스명.메서드명(Mockito.any(객체타입.class))).willReturn(객체명)
  ➜ Mock 객체인 해당 클래스로 해당 메서드를 호출하도록 정의함
  ➜ Mockito.any()는 어떤 타입으로 호출될지 지정
  ➜ .willReturn()은 위의 해당 메서드가 리턴할 Stub 데이터

✔️ Stubbing

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

---

✔️ Stub

• 호출시 항상 정해진 행동을 하거나 정해진 데이터를 돌려주는 컴포넌트
• 주로 테스트에서 사용하기 때문에 Test Stub이라고 함

---

✔ 슬라이스 테스트에 Mockito 적용

1. MemberController의 postMember() 테스트에 Mockito 적용

• @MockBean 애너테이션을 사용하여 가짜 객체로 만들 Service 클래스 지정 후, 필드에 DI  [@MockBean 참고]

• @Autowired 애너테이션을 사용하여 Dto 클래스를 감싸서 요청/응답을 처리할 mapper 클래스를 필드에 DI

 

Ex. MemberControllerMockTest 클래스의 postMemberTest()를 호출하여 실행한 결과

➜ MockMemberService의 createMember() 메서드가 호출되므로, 데이터 액세스 계층쪽의 로직은 실행이 되지 않음

➜ MockMemberService 클래스는 우리가 테스트하고자 하는 Controller의 테스트에 집중할 수 있도록 다른 계층과의 연동을 끊어주는 역할을 하는 것

 

2. MemberService의 createMember() 테스트에 Mockito 적용

• 클래스 레벨에 @ExtendWith(MockitoExtension.class) 적용
  ➜ Spring을 사용하지 않고, Junit에서 Mockito의 기능을 사용하겠다는 의미
• @Mock 애너테이션을 사용하여 Mock 객체로 만들 Repository 클래스 지정 후, 필드에 DI
• @InjectMocks 애너테이션을 사용하여 Mock 객체를 주입할 Service 클래스 지정 후, 필드에 DI

---

✏️ TDD (Test Driven Development)

• 테스트 주도 개발
• '테스트를 먼저 하고 구현은 그 다음에 한다'
  ( 테스트 케이스 먼저 작성 후, 그에 맞는 유효성 검증 로직이나 활용할 메서드 / 클래스들을 작성하여 failed 테스트 케이스를 passed로 바꿔주는 것 )

✔️ DDD (Domain Driven Design)
- 도메인 중심의 설계 기법

[참고 1], [참고 2]

---

✔ TDD 특징

• 모든 조건에 만족하는 테스트를 먼저 진행한 뒤, 조건에 만족하지 않는 테스트를 단계적으로 진행하면서 실패하는 테스트를 점진적으로 성공시켜 감
  
  
• 실행 결과가 failed인 테스트 케이스를 지속적으로 그리고 단계적으로 수정하면서 테스트 케이스 실행 결과가 passed가 되도록 만듦
  
  
• 테스트가 passed 될 만큼의 코드만 우선 작성
  
  
• 실패하는 테스트 → 실패하는 테스트를 성공할 만큼의 기능 구현 → 성공하는 테스트 → 리팩토링 → 실패하는 테스트와 성공하는 테스트 확인의 흐름 반복

---

✔ TDD 장점

• 테스트를 통과할 만큼의 기증을 구현
  ➜ 한번에 너무 많은 기능 구현 필요 X
  
  
• 테스트의 코드가 추가되면서 검증 범위가 넓어질 수록, 기능 구현도 점진적으로 완성
  ➜ 단순한 기능 -> 복잡한 기능으로 확장되면서 검증 빼먹지 않고 가능
  
  
• 리팩토링할 부분이 생기면 그때 그때 리팩토링 가능
  ➜ 리팩토링의 비용 상대적으로 적어짐
  
  
• 항상 테스트 케이스가 존재하므로 코드 수정에 대한 심리적 불안감이 줄어듦
  
  
• 리팩토링으로 꾸준히 코드를 개선하므로 코드의 품질을 일정부분 유지 가능
  
  
• 코드 수정 이후, 바로 테스트 가능
  ➜ 코드 수정 결과에 대한 빠른 피드백

---

✔ TDD 단점

• 아직 TDD 방식이 익숙치 않다는 점
  
  
• 테스트 코드 작성을 싫어하는 사람들에게는 부정적인 방식
  But, 실무에서는 결국 꼭 해야함
  
  
• 팀 단위로 개발이 진행되는 실무에서는 팀원들 간 사전 협의가 되어야함

---

😜 실습

• projects - be-template-testing-mock
• git - be-homework-testing-mock
  
  

But, 이번 실습은 Mapper를 테스트 대상으로 보고있지 않음 !

상황에 따라 Mapper도 매핑이 잘 되는지 테스트 가능 !

---

✔️ UriComponentsBuilder 클래스를 이용한 UriComponents 인스턴스 생성 방법

원래는 path 로 url을 지정할 때,

mockMvc.perform(get("/v11/members/"+member.getMemberId())); 이런 식으로 지정하였었는데

저 안에 직접 넣지 않고

URI uri = UriComponentsBuilder.newInstance().path("/v11/members").build().toUri();

위와 같이 UriComponentsBuilder 클래스를 이용하여 생성해줄 수 있다 !

이 경우 path에는 간단히

mockMvc.perform(get(uri)); 이렇게만 넣어주면 바로 생성 가능 !

[참고] https://blog.naver.com/PostView.naver?blogId=aservmz&logNo=222322019981

---

🌈 느낀점

Mockito가 들어가니까 좀 어려워졌다ㅠㅠ
사실 페어와 실습하면서 1시간 반동안 에러들을 해결하느라 2개의 테스트 케이스밖에 완료하지 못했다.
동작 방식과 동작 순서, 구성 등을 잘 익혀서 다른 코드를 참고하지 않고도 바로바로 테스트 케이스를 작성할 수 있도록 해야지

 

( 본 게시물은 2022/11/13에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90