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

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

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

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

통합테스트와 단위테스트 파일 분리

안녕하세요.강의에서는 두 테스트 방법을 별도로 구분해 말씀을 드리고 있지만, 단위, 통합을 구분하기보다는 파일 모듈 단위로 테스트를 작성한다 라고 이해해주시면 좋을 것 같습니다.

grid 양옆에 margin은 어디서 설정되어있는건가요 ?

안녕하세요. 답변이 조금 늦었는데요. 아마 말씀해주신 부분에 대한 스타일은 mui 컴포넌트에 적용되어있는 스타일로 보여집니다.개발자도구를 통해 화면에서 보여지는 스타일을 보여주시면 좀 더 확실히 특정할 수 있을 것 같은데요!혹시 궁금하시다면 추가로 댓글 남겨주세요~

vitest 설치했는데

안녕하세요. 답변이 조금 늦었네요 ㅠㅠ 죄송합니다.지금 당장 vitest 플러그인을 사용하지 않아도 강의를 진행하시는데는 문제가 없습니다.구체적인 원인은 조금 더 찾아보고 말씀 드리겠습니다만, 우선은 cli에 노출되는 결과를 기준으로 변경에 대한 부분이 테스트가 진행되니 강의를 진행해주시면 감사하겠습니다.

2부 할인쿠폰 관련

메일 주시면 다시 발급해드리겠습니다!