AvailableUsers

@Coi님 답변 늦어 죄송합니다 ㅠㅠ1. 여기서 play 안에 matcher를 넣지 않은 것은 Storybook을 시각적 상태 확인용으로 사용하려는 의도인가요? + 2. 그리고 이 컴포넌트의 동작 검증은 Storybook이 아니라 Vitest에서 담당하도록 역할을 나눈 것으로 이해하면 될까요?-> 넵 맞습니다! 시각적으로 검증하기 위해 활용했다라고만 이해해주시면 됩니다. 최근 트렌드가 변함에 따라 해당 부분에 대한 테스트를 스토리북에서 진행하는것도 가능해졌다고 이해하고 있는데요. 브라우저 기반의 테스트 코드 도구들도 많이 생겼구요. 결국 목적에 따라 각각 어떤 부분을 검증할지, 어디서 작성할지 명확하게 한다면 관리하기 편한곳에서 운영하셔도 됩니다.3. 실무에서는 보통 storybook을 어디까지 작성하는지 궁금합니다. - 물론 회사마다 다르겠지만, 강의해주시는 강사님 기준으로 의견을 듣고 싶습니다.-> 일반적으로 실무에서는 디자인 시스템을 운영한다면 해당 부분에 대해 전반적으로 운영을 하는 편이고, 그렇지 않다면 공통 컴포넌트들에 대한 관리 목적으로 그리고 시각적 테스트를 진행하면 해당 시나리오들에 대해서만 운영을 하는 편인것 같아요! 주로 스토리북을 테스트 관점에서도 운영할 수 있지만 여러 부서들 간의 커뮤니케이션 도구로 실제 결과를 보여주는 관점에서 사용하는 경우도 많이 있어서요. 해당 부분에 대해서도 고민해보시면 좋을것 같습니다!

mockZustand

안녕하세요 Coi님.replace 플래그를 넘긴 이유는 각 테스트 실행 시 완전한 격리를 통해 일관된 결과를 보장하기 위함입니다.테스트 실행전 혹여 이전 테스트 실행시 변경된 state와 merge 되면 영향을 받을 수도 있어서요. 테스트의 독립성을 보장하고, 의도치 않은 결과가 발생을 막기 위해 처리하였다고 이해해주심 됩니다.다만, 예제 프로젝트의 해당 플래그가 없어도 테스트가 잘 통과되긴하네요..ㅎㅎ 위에 적은 의도만 이해해주심 될 것 같습니다. 테스트의 독립 실행은 굉장히 중요한 포인트라서요. 실제로 실무에 도입하실때 이런 테스트 데이터 오염 이슈가 자주 있어서 인지하고 계심 도움될것 같습니다!

프로젝트 세팅 오류 및 버전 오류 문제 문의

수로님 답변이 늦었네요! 죄송합니다 ㅠㅠ우선 에러가 발생했던 부분에 대해 공유해주시면 좀 더 함께 살펴볼 수 있을 것 같습니다ㅠㅠ사실 node 버전이 낮고 버전이 낮은 부분은 있지만, 내부에 nvm 버전에 명시되어있는 노드 버전과 lock에 명시된 의존을 설치하면 에러가 발생하지 않아야 정상이어서요! 노드 버전이 nvm 버전과 일치되어 있는지, lock 파일에 맞춰 설치가 되어있는지 다시 확인해주시면 감사하겠습니다. 추가로 vitest 익스텐션은 이슈가 있는걸로 알고 있는데요. 이전에 관련해서 해결한 분이 있어 글 함께 공유 드려 봅니다. (링크)2-1강 같은 경우도 Windows/Mac OS 차이(LF, CRLF)로 발생하는 줄바꿈 문자 차이 에러가 나오고 영상에 나온 익스텐션에 경우 Vitest Version >= v1.4.0이라 vitest 및 vitest/ui 등 업데이트를 매번 해야됩니다. (강의는 v0.33.0)이 부분에 대해서도 여기 명시 되어있는 룰을 추가해서 사용해주시면 감사하겠습니다.https://github.com/practical-fe-testing/test-example-shopping-mall/issues/2 추가로 관련해서 최신 버전에 대한 업데이트는 주기적으로 검토하고 있는데요.https://inf.run/6F2M1요기 명시되어 있는 부분에서 크게 변경이 있었고, 최근 버전에 대해서는 수정이 많이 필요한 부분이 없어 업데이트를 하고 있지는 않습니다.혹시 최신 구성이 궁금하시다면 조만간 하나 더 다시 구성해서 올려보도록 하겠습니다. 추가로 궁금한 점 있으시면 편하게 남겨주세요! 감사합니다.

toggleIsModalOpened 테스트 할때 궁금한 점이 있습니다.

안녕하세요! 답변이 조금 늦었네요.말씀하신 것처럼 false → true → false 전체 흐름을 검증하는 것도 유효한 접근입니다.다만 초기값 검증은 상단 테스트에서 이미 했고, 나머지 테스트들은 각각 toggle, setTrue, setFalse가 상태를 올바르게 변경하는지만 확인하는 걸로 처리했습니다.말씀해주신 접근 물론 타당합니다. 지금처럼 단순한 경우엔 현재 구성으로 충분하지만, 상태 전이가 복잡해지면 시나리오 기반(말씀해주신!) 테스트가 더 유용할 수 있습니다.감사합니다!

로딩/에러처리 검증은 어떻게 하는게 좋을까요?

안녕하세요! 좋은 질문이네요.단순히 API 호출에 대한 것이 아닌 Error Boundary나 Suspense가 단순히 리액트 기능상 표준화된 제대로 동작하는 것을 검증하는 것이 아니라, 노출되는 조건이 복잡하거나 비즈니스 로직이 얽혀있는 경우에는 테스트를 진행하는 것이 좋아보입니다.말씀해주신대로 합성해서 사용할 수 있도록 여러 기능을 래퍼 형태로 작성해뒀다면, 검증을 진행하는 것이 좋습니다. ErrorBoundary와 Suspense가 함께 관리되는 컴포넌트기도 하고, 여러 곳에서 사용할 수 있는 공용 컴퍼넌트니까요.추가로 궁금하신점 있으면 편하게 질문주세요! 감사합니다.

통합 테스트에서 API 요청에 대한 검증은 이루어지지 않아도 괜찮을까요?

답변이 조금 늦었네요!승현님 안녕하세요. 정확하게 파악하셨습니다. 올바른 응답이라고 가정을 진행하기 때문에 빠른 테스트, 다양한 시나리오 검증, 화면에 집중할 수 있는 부분들이 장점으로 있지만, 모킹하는 지점이 생기게 되면 제대로 검증을 못하게 되는 부분이 생기게 됩니다. MSW를 구성하는 것 또한 실제 구현과 싱크가 안맞게 될 수 있는 부분이기 때문에 검증이 정확하지 않을 수 있구요.이런 경우에는 2부에서 소개되는 E2E 테스트가 어느정도 해결책이 될 수 있는 부분이라고 생각합니다. 실제 API 통신을 발생시키고 서버에서 응답을 받아 해당 시나리오에 맞춰 검증을 진행할 수 있으니까요.앱 관점에서의 전체적인 흐름을 검증하기에 적절한 부분이라고 생각합니다. 혹시 추가로 궁금한 점 있으시면 편하게 답변주세요!

e2e 테스트 CI , 서버비용

안녕하세요 여어님!말씀해주신 대로 e2e 테스트는 실제 사용자와 같은 환경에서 전체 시스템의 흐름을 검증하는 매우 중요한 과정이지만, 실행 시간과 비용이 많이 들어 관리하기가 까다롭죠. 단위 테스트나 통합 테스트에 비해 즉각적인 피드백을 받기 어렵고 개발 생산성을 저해할 수도 있습니다.질문 주신 부분과 약간은 다르지만, 저는 개인적으로 기능 관점에서의 테스트에서 Node.js환경에서 구동되는 단위-통합테스트와 E2E 테스트가 있다면 둘 다 검증이 가능한 경우 단위 - 통합 테스트에 작성을 해 E2E 테스트에서 운영이 되어야 하는 테스트들을 가능하면 중요한 시나리오 위주로 유지하려고 노력하고 있습니다.또한, Playwright의 경우 이미 제공하고 있고, Cypress의 경우 유료 결제나 Sorry Cypress 등의 온프레미스 형태로 무료로 사용할 수 있는 도구들을 활용해 테스트를 병렬로 구동하는 방식도 시간을 줄일 수 있는 방법입니다. 추가로 여어님께서 리서치하신 스케줄 실행(Nightly/주말)과 온디맨드 실행(PR 코멘트/수동 트리거)을 병행하는 전략은 현업에서 매우 많이 쓰이는 방법입니다. 실제로 많은 팀이 이 두 가지 방식을 기본 축으로 삼아 E2E 테스트를 관리하고 있습니다. 검증해야 하는 시나리오별로 중요도, 상황에 따라 그룹핑을 하고 테스트를 말씀해주신대로 운영한다면 시간을 조금 더 줄일 수 있는 방법으로 보입니다. 좋은 질문 감사합니다!혹시 추가로 궁금하신점 있다면 편하게 남겨주세요~

단언문 순서에 따라 테스트 결과가 왜 달라지나요?

안녕하세요 Einere님~!우선 말씀주신 대로 아래의 코드도 정상적으로 통과해야 합니다.expect(screen.getByTestId('cart-icon')).toBeInTheDocument(); expect( await screen.findByRole('button', { name: 'Maria' }), ).toBeInTheDocument(); expect(screen.getByText('2')).toBeInTheDocument(); NavigationBar.jsx 파일에 로그인 했을 경우 해당 장바구니의 데이터를 로컬 스토리지에서 가져와 설정하는 코드가 있는대요.const { data, remove } = useProfile({ config: { onSuccess: profile => { setUserData(profile); // 장바구니 데이터 설정 initCart(profile.id); }, enabled: !!isLogin, }, });로그인 상태일 경우, 프로필 조회 API가 실행initCart(userId)실행로컬 스토리지에서 해당 userId에 해당하는 cart 정보를 가져와 설정(/store/cart.js))테스트 환경에서는 로컬 스토리지 데이터가 존재하지 않음3번째 use case를 놓친채로 테스트 로직이 작성되어 코드 수정이 필요한 부분입니다.아래의 코드처럼 테스트 환경의 로컬 스토리지에도 cart mock 데이터를 설정하면 테스트는 정상적으로 통과합니다.import { screen, within } from '@testing-library/react'; import { rest } from 'msw'; import React from 'react'; import NavigationBar from '@/pages/common/components/NavigationBar'; // 모듈 추가 import { setCartToLocalStorage } from '@/store/cart'; import { mockUseUserStore, mockUseCartStore, } from '@/utils/test/mockZustandStore'; // ... beforeEach(() => { // ... const cart = { // ... }; // 아래 코드 추가 setCartToLocalStorage(cart, userId); mockUseCartStore({ cart }); });정리하자면 말씀하신대로 단언문의 순서와 무관하게 테스트가 통과하는 것이 맞습니다.(코드 수정 링크)제보해주셔서 감사드립니다..!감사합니다.

useNavigate 테스트 시, 검증 대상 질문입니다.

안녕하세요! 답변을 남기려고 했는데, 아래 AI가 답변을 나름 정확하게 남겨놨네요 ㅎㅎ단위 통합테스트에 있어서는 실제 페이지 이동이 올바르게 되었는지를 검증하기 어렵기 때문에, 그리고 해당 동작을 구현하는데 있어서 이미 구현되어있는 라이브러리를 사용하기 때문에 말씀해주신것처럼 검증을 한다고 해서 더 높은 신뢰성을 얻기는 어려울 것 같아요. 모킹의 어려움, 복잡성도 더 늘어날 것 같구요.이같은 맥락에서 아래 답변을 참고해주시면 감사하겠습니다!

강의 예시프로젝트 업데이트좀 부탁드립니다.

안녕하세요 ㅎㅎ 프로젝트 세팅에 어려움을 겪고 계시군요..혹시 어떤 부분 어려우셨는지 말씀해주시면 최대한 빠르게 답변 드려보겠습니다~ 편하게 질문 남겨주세요~