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부 할인쿠폰 관련

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

에러 해결 방법

안녕하세요~AI 인턴 친구가 남겨주신 것처럼 아마 노드 버전의 문제이지 않을까 싶습니다.사용하시는 노드 버전이 22버전이라고 되어있는데, 강의는 19버전을 사용하고 있어서요.가능하다면 nvm use 를 통해 버전을 맞춰 강의를 진행해주시거나 현재 버전으로 진행하고 싶으시다면 assert 대신 with로 구문을 변경해서 사용해주시면 될 것 같습니다. 관련 이슈도 올려드릴게요!감사합니다~https://stackoverflow.com/questions/78876691/syntaxerror-unexpected-identifier-assert-on-json-import-in-node-v22

Retry-ability와 커스텀 커맨드, 커스텀 쿼리 질문

안녕하세요 메가님! 답이 조금 늦었네요 ㅠㅠ 죄송합니다.1. 커스텀 쿼리도 Retry-ability 지원되고 커스텀 쿼리 안에 커맨드도 Retry-ability가 지원되면 n의 m제곱 번의 재시도가 발생하는 것일까요?이 부분은 실제 구현을 참고해봐야 할 것 같은데요. 제가 구현을 했다고 가정을 하고 감히 추측을 해보면, n의 m승으로 재시도가 발생하는 경우 그렇게 재시도 시기의 검증 효용이 없다고 판단하고(적다 보니 아닌 경우도 있을 수 있을 것 같네요) 최적화를 했을 것 같은데 cypress측에 문의를 해봐야 할 것 같네요 ㅎㅎhttps://github.com/cypress-io/cypress/issues요기에 문의를 진행해보시면 어떨까 싶습니다!2. 커스텀 커맨드와 커스텀 쿼리 중에 뭘 사용할 것인지는 Retry-ability 지원 유무와 체이닝을 기준으로 선택하면 될까요?예시코드를 봤을 때 getCardButton와getProductCardByIndex 둘 다 DOM 요소를 조회해서 subject를 리턴하여 체이닝을 통해 후속 작업을 하는 것처럼 보이는데 왜 getProductCardByIndex는 커스텀 커맨드로 작성하는지 잘 모르겠습니다.. 말씀해주신대로 Query가 붙은 API와 안붙은 API의 가장 큰 차이는 retry-ability지원 여부입니다.Query가 붙은 API는 동기 방식으로 동작하며 이전까지 체이닝으로 사용한 커맨드의 subject 결과를 받아 사용합니다. 그리고 체이닝으로 연결된 코드를 일정 시간동안 재시도합니다.(https://docs.cypress.io/api/cypress-api/custom-queries)반대로 Query가 붙지 않은 커스텀 커맨드는 비동기로 동작할 수 있으며, 특별한 설정을 하지 않으면 이전의 subject를 이어 받아 사용하지도 않습니다.또한 내부적으로 재시도를 실행하지 않고 단 한번만 실행합니다.예시의 경우 아마 강의 특성상 여러 방법이 있다고 소개를 드리려고 하다보니 직접적이게 와닿는 예시가 아닐 수 있는데요. 이 부분은 죄송합니다. 목적에 맞게 선택해 구현한 뒤 사용하면 됩니다.