실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
시각적 회귀 테스트 강의의 Storybook 코드에서 play 함수 안에 matcher를 넣지 않고 userEvent.click(...)만 사용한 이유가 궁금합니다. import { userEvent, within } from '@storybook/testing-library'; import AvailableUsers from '@/pages/login/components/AvailableUsers'; export default { component: AvailableUsers, title: '로그인/사용자 리스트', }; export const Folded = { name: '접힌 상태', }; export const Expanded = { name: '펼친 상태', play: async ({ canvasElement }) => { const canvas = within(canvasElement); await userEvent.click(canvas.getByText('⚠️ 사용 가능한 유저 리스트')); }, }; 제가 이해한 바로는, 이 스토리는 storybook에서 아코디언이 펼쳐진 시각적 상태 변화를 보여주기 위한 용도이고, 실제 기능 로직 검증은 Vitest에서 별도의 테스트 코드로 작성하는 방향이라고 생각했습니다. 1. 여기서 play 안에 matcher를 넣지 않은 것은 Storybook을 시각적 상태 확인용으로 사용하려는 의도인가요? 2. 그리고 이 컴포넌트의 동작 검증은 Storybook이 아니라 Vitest에서 담당하도록 역할을 나눈 것으로 이해하면 될까요? 3. 실무에서는 보통 storybook을 어디까지 작성하는지 궁금합니다. - 물론 회사마다 다르겠지만, 강의해주시는 강사님 기준으로 의견을 듣고 싶습니다.
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
안녕하세요 e2e 테스트는 비용이 많이 들어서 어떻게 관리를 하는지 궁금합니다. - 파이프라인에서 매번 CI 에서 돌리기에는 서버나, 시간이 개발 생산성을 잡아 먹을 것 같은데요. 점점 e2e 테스트가 쌓여 나갈떄 어떤 전략을 취할 수 있는지 궁금해요. GPT로 리서치하니까 보통 2가지를 병행해서 스케줄러 + 온디맨드 실행 같이 관리 한다고 하는데, 실제 현업에서는 어떻게 활용하고 계신지, 제가 리서치한 내용 말고 더 효율적이거나, 추천할만한 전략 , 이외의 고려사항 소개해주실 수 있으면 알려주시면 감사하겠습니다. 스케줄 실행 (Nightly/주말 풀스윗) EventBridge → ECS Fargate RunTask (Spot 가능) → Playwright 러너 대상: 스테이징(or PR 프리뷰 URL) b. 산출물: 트레이스/비디오/리포트 S3 업로드, Slack에 요약/링크 온디맨드 실행 (PR 코멘트/수동 트리거) Bitbucket Pipeline에서 aws ecs run-task 호출(또는 ChatOps 슬래시 커맨드) 태그/폴더/샤드 인자 넘김 → 필요한 부분만
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
안녕하세요 선생님 강의 잘 듣고 있습니다. 이번 강의에서 질문이 있습니다! 1. 커스텀 쿼리도 Retry-ability 지원되고 커스텀 쿼리 안에 커맨드도 Retry-ability가 지원되면 n의 m제곱 번의 재시도가 발생하는 것일까요? 2. 커스텀 커맨드와 커스텀 쿼리 중에 뭘 사용할 것인지는 Retry-ability 지원 유무와 체이닝을 기준으로 선택하면 될까요? 예시코드를 봤을 때 getCardButton 와 getProductCardByIndex 둘 다 DOM 요소를 조회해서 subject를 리턴하여 체이닝을 통해 후속 작업을 하는 것처럼 보이는데 왜 getProductCardByIndex 는 커스텀 커맨드로 작성하는지 잘 모르겠습니다..
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
질문 git clone https://github.com/practical-fe-testing/test-example-shopping-mall.git 를 했는데 폴더안에 gitignore 과 readme 파일만 있는데 해당 브랜치를 clone해서 사용하는게 아닌건가요? 참고사항 대체방안으로 zip파일로 다운받아서 사용하고 있긴합니다!
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
unit-test-example에서 테스트를 실행하니 테스트코드 통과 여부에 관계없이 Test result not found만 뜨며 실패합니다. 이유를 모르겠어요ㅠㅠ Test result not found. If you set `vitest.commandLine` please check: Did you set `vitest.commandLine` to `run` mode? (This extension requires `watch` mode to get the results from Vitest api) Does it have the ability to append extra arguments? (For example it should be `yarn test --` rather than `yarn test`) Are there tests with the same name? Can you run vitest successfully on this file? Does it need custom option to run?
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
시간: 9:00 Q. ‘비밀번호를 입력하지 않고 로그인 버튼을 클릭할 경우 “비밀번호를 입력하세요” 경고 메시지가 노출된다’ 를 테스트 할 때, 비밀번호가 입력하지 않은 상태인지 확인하는 부분은 없어도 되는 건가요?? 비밀번호를 입력하는 요소가 null 인지 확인하는 테스트는 없어도 되는 건가요??
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
Q1. 장바구니, 구매 버튼 클릭 시 해당 상품의 이름을 cy.findByText('Handmade Cotton Fish 장바구니 추가 완료!').should('exist) 상품 이름을 직접 입력하는데, (통합 테스트에서 모킹 데이터를 사용한다면 모킹 데이터는 직접 설정하기 때문에 가능하지만), 실제 api를 사용하면 첫번째 상품 데이터가 변경할 수도 있기 때문에 실패할 수도 있기 때문에 다르게 작성해야 하지 않을까요?? 질문 드립니다 Q2. 로그인을 커스텀 커맨드에서 설정해서 session을 사용해 설정해서 테스트할 때, 웹에서는 로그인 성공/실패 여부는 확인할 수 없는 것 아닌가요?? 로그인이 실패하게 되면 로그인 관련 테스트는 모두 실패하게 되는데 그냥 이 결과로 로그인 성공/실패 확인을 하는 건가요??
실무에 바로 적용하는 프런트엔드 테스트 - 2부. 테스트 심화: 시각적 회귀・E2E 테스트
Q. cy.intercept()는 회원 가입 요청에 대한 성공/실패 응답을 모킹해서 받는데, 이 때 의도하는 코드는 1번이지만 응답이 정해져 있기 때문에 2번처럼 틀린 요청으로도 결과는 똑같이 나오게 될 거라고 생각됩니다. 실제 응답이 아니라 응답을 정해 놓고 전달하기 때문에 실제 동작과 다를 수도 있어서 이 부분은 '실패, 성공 시 문구 노출'이 나타나는 동작이 있다는 document 로만 이해해도 될까요?? 1 성공 데이터 요청 -> 성공 데이터 응답 실패 데이터 요청 -> 실패 데이터 응답 2 실패 데이터 요청 -> 성공 데이터 응답 성공 데이터 요청 -> 실패 데이터 응답
