인프런 커뮤니티 질문&답변

BB Dev님의 프로필 이미지

작성한 질문수

실무에 바로 적용하는 프런트엔드 테스트 - 1부. 테스트 기초: 단위・통합 테스트

5.1. 통합 테스트 작성하기 - ProductFilter

통합 테스트 작성 방식에 대해 궁금한 점이 있습니다

해결된 질문

작성

·

68

0

  1. 테스트는 내부 구현에 의존하지 않고 사용자 입장에서 작성하는게 좋다고 이해했습니다.
    그런데 ProductFilter 컴포넌트의 통합테스트를 작성하시면서 "상품명을 수정하는 경우 setTitle 액션이 호출된다", "최소 가격 또는 최대 가격을 수정하면 setMinPrice와 setMaxPrice 액션이 호출된다" 와 같이 사용자가 값을 변경할 때 특정 액션 함수가 호출되는지를 검증하셨는데, 이건 내부 구현에 의존적인 테스트라고 볼 수 없을까요?
    추후 Store 내부 구조가 바뀌거나 아예 Store를 사용하지 않는 식으로 구현 방법이 바뀌더라도 사용자 입장에선 달라지는게 없으니 테스트가 실패하지 않는게 좋은 테스트가 아닌지 궁금합니다.

    2. api를 호출하는 커스텀 훅을 사용하는 컴포넌트를 테스트하실 때 msw를 이용해 해당 api의 응답을 모킹하셨는데, 커스텀 훅 자체를 모킹해서 훅이 반환하는 값을 원하는대로 지정하는 것도 가능할 것 같습니다. 이렇게 api 대신 훅을 모킹하여 테스트하는 것에 대해 어떻게 생각하시는지 궁금합니다.

답변 2

0

코드 조커, 오프님의 프로필 이미지
코드 조커, 오프
지식공유자

안녕하세요! 답변이 조금 늦었네요 ㅠㅠ

  1. 넵 맞습니다. 내부 구현에 대한 의존적인 테스트라고도 볼 수 있을 것 같습니다. 당시 코드를 작성했을 때 기억을 되살려보면.. ProductFilter에 대한 통합테스트이고 값이 변경되었을 때 실제 화면에서 적절하게 변경되었다라는 것을 인지할 수 있는 부분은 각 아이템들에 대한 값이 제대로 노출되는지 여부 정보만 검증할 수 있다고 생각했던것 같습니다. 추가로 필터로 지정된 값으로 더 외부에서 노출되는 아이템이 달라지기 때문에 영향을 미칠 수 있는 store set 함수를 테스트하지 않았나 라고 생각이 듭니다.


현재 테스트 구조상 E2E 테스트에서 실제 필터값의 결과를 테스트하고 있기 때문에 올바른 동작을 검증하고 있습니다. 그래서 Home에 대한 페이지의 통합테스트는 따로 작성되지 않았는데요. 만약 E2E테스트를 사용하지 않고 좀 더 통합테스트에서 해당 동작을 검증하고 싶다면 Home에 대한 통합테스트를 작성해서 실제 결과를 검증해보면 말씀해주신 사용자 관점의 테스트가 될 것 같습니다.!

 

  1. 만약 훅 자체를 반환한다면 훅을 사용하는 컴포넌트 내에서 훅에 대한 검증이 사라지게 되는데요. API 응답만을 모킹하게 되면 해당 훅에 대한 동작은 함께 검증할 수 있기 때문에 두 테스트의 검증 범위가 달라지게 됩니다. 따라서, 테스트 목적에 맞게 판단해서 진행하면 될 것 같습니다.

BB Dev님의 프로필 이미지
BB Dev
질문자

답변 감사합니다!

0

안녕하세요, 인프런 AI 인턴입니다.

  1. 테스트는 사용자의 관점에서 목표하는 바를 개발자가 이해하고, 해당 목표를 달성하는 기능이 제대로 작동하는지 확인하는 것에 중점을 두는 것이 중요합니다. 하지만 “상품명을 수정하는 경우”와 같이 특정 상호작용이 예상하는 로직을 실행하는지 검증하는 것 역시 중요할 수 있습니다. 이는 내부 구현에 대한 테스트이기는 하지만, 중대한 비즈니스 로직이나 사용자와의 상호작용을 검증하는 경우에는 필요할 수 있습니다. 이런 테스트는 구현이 변경될 때마다 업데이트가 필요할 수 있으나, 중요한 작동 방식을 보장하기 위한 것입니다. 궁극적으로 테스트의 목표는 사용자가 겪게 될 문제를 미리 발견하고, 소프트웨어가 의도한 대로 작동함을 보장하는 것입니다. 그러나, 가능하다면 사용자의 경험에 직접적으로 영향을 미치는 결과물 위주로 테스트를 구성하는 것이 더욱 바람직하다고 볼 수 있습니다.

  2. API를 호출하는 커스텀 훅의 테스트에서 MSW(Mock Service Worker)를 사용해 API 응답을 모킹하는 접근 방식은 실제 네트워크 요청의 흐름을 에뮬레이션 함으로써 테스트의 신뢰성을 높일 수 있습니다. 커스텀 훅 자체를 모킹하면 테스트가 더 단순해지고 빨라질 수 있으며, 특정 상황을 더 쉽게 재현할 수 있습니다. 하지만 이 경우, 훅이 외부 요청과 상호작용하는 방식을 정확히 반영하지 않을 수 있어 전체적인 흐름을 검증하는 데는 한계가 있을 수 있습니다. 따라서, 테스트의 목표와 필요에 따라 접근 방식을 선택하는 것이 좋습니다. 실제 네트워크 요청의 흐름을 테스트하려면 MSW를 사용하는 것이 좋고, 내부 로직이나 상태 관리에 중점을 둔 테스트를 작성하고자 한다면 훅을 모킹하는 방법을 선택할 수 있습니다.

BB Dev님의 프로필 이미지

작성한 질문수

질문하기