프론트엔드 테스트시 모킹 범위가 궁금합니다.

테스팅에서 모킹 기법은 잘 쓰면 좋은 약이 되지만 잘못 쓰면 독이 될 수도 있기 때문에 Tradeoff를 잘 고려하셔야 합니다. MSW를 사용하여 API 연동을 모킹하면 가볍고 빠르며 안정적인 결과를 내는 테스트를 작성할 수 있지만, 그에 대한 대가로 해당 테스트는 실패해야 하는 상황에서도 통과하게 될 위험이 높아지게 됩니다. 왜냐하면 테스트가 실행할 때 실제 백앤드 API와 네트워크 통신이 일어나지 않기 때문입니다. 즉, 나중에 백앤드 API가 변경이 일어났을 때 해당 테스트는 여전히 통과할 것입니다. 그리고 이러한 위험은 특히 프론트앤드와 백앤드를 서로 다른 팀이 유지보수하거나, 외부 API를 사용할 때 더 높아지게 되죠. 이렇게 Unit 테스트 수준에서 모킹으로 인해서 발생하는 부작용을 최소화하기 위해서, 그 보다 상위 수준의 테스트(Integration, E2E)에서는 모킹을 금지하거나 제한하는 경우가 많습니다. 예를 들어, 실제 백엔드 API와 네트워크 통신을 하는 E2E 테스트를 보강하면, Unit 테스트가 통과하더라도 E2E 테스트가 실패하게 되어 예상치 못한 백엔드 API가 변경에 효과적으로 대응할 수 있습니다. 또 다른 대안으로 Contract 테스트라는 것도 있는데, 이 부분까지 설명하면 답변이 너무 길어질 것 같아서 따로 구글링해보시면 좋을 것 같습니다. React 개발에서 모든 컴포넌트 함수에 대한 Unit 테스트를 작성하는 것이 정석적인 방법이나 프로젝트에 따라서 개발 생산성을 위해서 어느 정도 타협하는 경우도 있습니다. 예를 들어, `<Button/>`이나 `<Input/>`과 같은 하위 수준의 컴포넌트에 대한 Unit 테스트는 생략하고, `<ProductDetai/>`이나 `<CheckoutForm/>`과 같은 비지니스에 중요한 컴포넌트를 위주로 Integration 테스트만 하는 것이지요. 하지만 만약에 프로젝트가 특정 비지니스를 위한 애플리케이션 개발이 아니라, UI 라이브러리 개발이라면 하위 수준의 컴포넌트에 대한 Unit 테스트도 필수적일 것입니다. Integration 테스트를 위주로 작성하는 경우에는 비지니스 로직을 커스텀 훅이나 별도 함수로 추출해놓지 않더라도 적어도 테스팅 측면에서는 큰 지장은 없습니다. 어차피 컴포넌트와 커스텀 훅이 함께 테스트가 될테니까요. 하지만 코드 가독성이나 유지 보수 측면까지 고려하신다면, UI 컴포넌트에서 비즈니스 로직을 분리하는 것은 여전히 권장됩니다. 혹시 도움이 될까해서 예전에 모킹 관련해서 올렸던 게시물 아래에 공유드리오니 참고 바랍니다. - Jest의 jest.mock()을 이용한 모듈 모킹: https://careerly.co.kr/comments/89815 - Jest의 jest.fn(), jest.spyOn()를 이용한 함수 모킹: https://careerly.co.kr/comments/89329 - MSW로 백엔드 API 모킹하기 (for 프론트엔드 개발자): https://careerly.co.kr/comments/88082