[Day 16] Mock을 마주하는 자세

[devmeeple]

7.3 @Mock, @Spy, @InjectMocks

• 순수 Mockito를 사용한 검증, 어떻게 하면 좋을까?

7.3.1 @Mock

• @Mock은 Mockito.mock을 편리하게 사용할 수 있게 도와준다.
  • 단, @ExtendWith(MockitoExtension.class)를 추가해야 기능을 활성화 한다. (선언하기)
• 구체적인 동작이 필요하지 않은 경우(메서드 호출, 간단한 값을 반환) 주로 사용한다.

7.3.2 @InjectMocks

• 테스트 대상 객체(SUT, System Under Test)에 @Mock으로 선언한 객체의 의존성을 추가할 때 사용한다.
  • 함께 사용할 때 배로 편리하다.

7.3.3 @Spy

• 일부는 실제 객체의 기능을 사용하고, 일부는 Stub 하고 싶을 때 사용한다.
• 실제 객체를 기반으로 만들어진다.

결론

• 전부 Mocking을 조금 더 쉽게 사용할 수 있도록 돕는다. 상황에 맞춰 어떻게 사용해야 하는지 고민하자.
• @Mock은 자주 사용한다. 상대적으로 @Spy는 조금 덜 사용한다.
• 개념은 비슷하지만 어떤 기능을 사용하냐에 따라 문법도 달라진다.

[devmeeple]

7.3 @Mock, @Spy, @InjectMocks

• 학습 테스트를 작성해서 사용법을 알아보면 좋을 것 같다.
• 향로님께서 ts-mockito글을 작성해 주셨다. 이 외에도 jest-mock-extended도 들었던 것 같다. (인프런 발표) 함께 사용법을 알아보자.
• 상황에 맞춰 사용할 수 있도록 예제를 만들고 각 도구의 사용을 배우자.

<참고 자료>

• Mockito framework site
• 향로 'jest.mock 보다 ts-mockito 사용하기 (feat. Node.js)'

[devmeeple]

테스트는 왜 필요한가요?

우선 고민해야 하는 내용이다. 사람은 비용의 한계가 있다. 함께 자라는 소프트웨어의 속도를 따라잡기란 불가능하다.

테스트는 소프트 웨어의 핵심 가치 '변화'에 우연하게 대응하기 위해 필요하다. 컴퓨터의 도움을 받는다.

하지만 테스트 코드 또한 비용이 필요하다. 잘못된 테스트 코드는 오히려 생산성을 감소시킨다. 따라서 어떻게 테스트 코드를 잘 작성할 수 있을까? 알아보자.

단위 테스트

JUnit 작은 단위란 무엇인가 해피 케이스 경계 케이스 제어할 수ㅜ없는 것에 의존 어떻게 용이하게 현재시간 랜덤값

TDD

영역을 자연스럽게 분리하게 된다. 테스트 하기 쉬운 코드, 쉽게 발견하기 어려운 엣지 케이스를 고민하게 한다. 클라이언트 관점에서 코드를 고민할 수 있게 돕는다.

테스트는 문서다

강조하고 또 강조한다. 왜 문서여야 하냐, 우리는 '팀 이니깐'.... 쿠버네티스 인용

디스플레이 네임 섬세하게 BDD 언어가 사고를 제한한다.

실무에서

그래서 어떻게 실무에서 적용해야 하나요? 레이어별 관심사가 다르니 테스트가 필요하다.

통합 테스트는 무엇인가? 단위 테스트로 검증하지 못하는 부분, 결합된 객체를 검증한다.

저장소와 서비스는 통합테스트로 작성한다.

통합 테스트를 부정적으로만 바라봤는데 다른 관점에서 바라보는 계기가 됐다.