ProductFilter test 어떤 방식이 더 선호되는 방식일까요?

안녕하세요!크게 검증하는 내용은 달라지지 않을 것 같습니다. 연속적으로 입력을 하더라도 실제 구현적인 관점에서 달라지는 부분은 없으니까요. 만약 순서를 변경하는것으로 개선을 도모하셨다면 두 테스트를 나눠서 작성하는 것도 좋을 것 같습니다 ㅎㅎ 말씀해주신 패턴대로 적용도 가능하고 각 검증 범위를 나눠 테스트 케이스를 작성했기 때문에 실패했을 때 어느 부분에서 문제가 발생했는지 훨씬 더 쉽게 알 수 있을 것 같아요!it('최소 가격을 수정하면 setMinPrice가 호출된다.',it('최대 가격을 수정하면 setMaxPrice가 호출된다.',

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

안녕하세요! 답변이 조금 늦었네요 ㅠㅠ 넵 맞습니다. 내부 구현에 대한 의존적인 테스트라고도 볼 수 있을 것 같습니다. 당시 코드를 작성했을 때 기억을 되살려보면.. ProductFilter에 대한 통합테스트이고 값이 변경되었을 때 실제 화면에서 적절하게 변경되었다라는 것을 인지할 수 있는 부분은 각 아이템들에 대한 값이 제대로 노출되는지 여부 정보만 검증할 수 있다고 생각했던것 같습니다. 추가로 필터로 지정된 값으로 더 외부에서 노출되는 아이템이 달라지기 때문에 영향을 미칠 수 있는 store set 함수를 테스트하지 않았나 라고 생각이 듭니다. 현재 테스트 구조상 E2E 테스트에서 실제 필터값의 결과를 테스트하고 있기 때문에 올바른 동작을 검증하고 있습니다. 그래서 Home에 대한 페이지의 통합테스트는 따로 작성되지 않았는데요. 만약 E2E테스트를 사용하지 않고 좀 더 통합테스트에서 해당 동작을 검증하고 싶다면 Home에 대한 통합테스트를 작성해서 실제 결과를 검증해보면 말씀해주신 사용자 관점의 테스트가 될 것 같습니다.! 만약 훅 자체를 반환한다면 훅을 사용하는 컴포넌트 내에서 훅에 대한 검증이 사라지게 되는데요. API 응답만을 모킹하게 되면 해당 훅에 대한 동작은 함께 검증할 수 있기 때문에 두 테스트의 검증 범위가 달라지게 됩니다. 따라서, 테스트 목적에 맞게 판단해서 진행하면 될 것 같습니다.

unit-test-example 브랜치에서 'Test result not found.' 가 뜹니다...

안녕하세요! 문제 해결에 정보가 조금 부족한 것 같은데요.의존을 어떻게 설치하고 실행하셨는지 정보를 조금 더 주실 수 있을까요?

vitest Extension 알려주세요.

안녕하세요~여기 확인해주세요!https://vitest.dev/guide/ide실험실 문양이 아니라 익스텐션 설치에 가셔서 vitest 살펴보시면 될 것 같습니다~

2.1 강의 질문있습니다.

안녕하세요.혹시 해당 코드가 어디서 사용되었는지 알 수 있을까요?

useNavigate()을 검증할 때 이해가 안되는 부분이 있습니다.

안녕하세요!실제 코드를 먼저 살펴보면//ErrorPage.jsx // useNavigate를 호출해서 반환된 함수가 navigate에 할당 const navigate = useNavigate(); const handleClickBackButton = () => { navigate(-1); // 할당된 함수를 -1 파라미터와 호출 };이기 때문에 실제 코드의 흐름과 동일하게 작성되도록 useNavigate 함수를 호출했을때 반환된 함수가 navigate에 할당되도록 작성되어있기 때문에 위처럼 전달되도록 작성했습니다.따라서 작성해주신expect(navigate함수에 전달된 spyFn).toHaveBeenNthCalledWith(1, -1)흐름대로 작성되었으며, 이를 통해 navigate가 호출이 다음과 같은 파라미터로 몇 회 호출 되었다 라는 것을 검증할 수 있게 됩니다. 혹시 추가로 궁금한 점이나 제가 잘못 설명한 부분이 있다면 알려주세요! 감사합니다.

toHaveStyle 메서드 사용이 조금 이상한 것 같습니다.

안녕하세요.우선 관련해서 올려주신 toHaveStyle 어설션은 px뿐만 아니라 이전 이슈에 올라왔던 1 처럼 유효하지 않은 값들은 비교상에서 없는 값으로 인식되어 비교가 올바르게 되지 않고 통과되는 것으로 보입니다. textInput에 존재하는 모든 스타일을 입력해야만 비교가 가능한 것이 아니라 partial 매칭 방식이기 때문에 다음과 같은 구현 방식을 따르지 않았나 싶습니다. 올바르게 비교하기 위해서는 스타일에 따른 올바른 양식의 값을 입력해주시면 될 것 같습니다~

TestPayment에 쿠폰 정보를 prop으로 전달하는 이유

안녕하세요! albert H님.useCouponList에서 RHF를 사용하고 있기 때문에 간단한 래핑을 통해 구성했습니다. 만약 useCouponList에서 RHF의 결합을 끊고 외부에서 주입하는 형태로 구현이 된다면, 별도 컴포넌트 모킹은 필요없을 수 있습니다.현재는 할인 금액만 검증하고 있는데요! 선택한 쿠폰의 이름을 검증하는 것도 좋아 보입니다.감사합니다.

NavigationBar 테스트 속도가 너무 느린 문제

안녕하세요! albert H님.NavigationBar 컴포넌트 자체가 다른 컴포넌트들에 비해 테스트 속도가 느린 파일은 아닌데요 ㅠㅠ아무래도 구동하는데 장비의 영향을 받거나 이미 실행중인 다른 프로그램의 영향을 받을 수 있을 것 같습니다.https://vitest.dev/guide/improving-performancevitest에서 제공하는 성능 증가 관련 글인데요. 이 부분을 한 번 적용해보시는 것도 좋을 것 같습니다.

안녕하세요, 단위 테스트 대상 관련해서 질문있습니다.

안녕하세요! TAEHEE JANG님코드를 보면 의견이 조금 달라질 수 있을 것 같지만, 우선 제공해주신 내용을 기준으로 답변 드리겠습니다.개인적으로는 이미 구현이 되어있는 Web API는 테스트를 할 필요가 없습니다. 이런 테스트를 통해 기대하는 동작을 확인해 보기 어려울 수 있고, 의미 있는 테스트라고 보기는 어려울 것 같습니다. 이런 동작들은 저희 테스트 환경에서 JSDOM에 구현이 되어 있는데 실제 브라우저의 동작과 다른 부분이 있기 때문에 잘 동작한다 한들 실제 브라우저에서 잘 동작되는 것과는 의미가 다릅니다. (https://ui.toast.com/posts/ko_20220624)그것과 별개로 해당 동작은 브라우저에서 관할하는 부분이며 문제가 발생하고 예상대로 동작하지 않는 부분을 가정하고 검증하는 것이 필요가 없을 것 같습니다. 마치 외부 라이브러리 처럼 문제가 발생해도 저희들이 관여할 수 없는 영역은 테스트의 영역에서 분리를 하는 것이 좋습니다.다만, 말씀해주신것처럼 조건에 따라 Web API가 호출되는 것처럼 해당 코드를 호출된 이후의 동작은 정상적일것이라는 '가정하에' 해당 동작을 스파이로 검증한다면, 그정도는 충분히 검증할 수 있는 부분이라고 볼 수 있을 것 같습니다. (다만, 일부분에 대한 검증이기 때문에 여전히 아쉽기는 할 것 같습니다.)추가로 저희는 테스트하는 환경에서 JSDOM을 활용하는데요. JSDOM에서 해당 동작을 지원하는지 확인해보면 좋을 것 같습니다. (https://github.com/jsdom/jsdom/issues/2032)추가로 궁금한 점 있으시면 질문 주세요! 감사합니다.