이전 게시물에서 Cypress로 E2E 테스트 코드를 작성하고 팀 내 프런트엔드 부분과 공유했습니다.
https://mingg123.190
(Cypress) NX + React + MUI + TS + Formik Cypress 고려
테스트 코드의 필요성 싸이프레스를 선택한 이유 싸이프레스 실행 명령어의 범위 테스트 영역 싸이프레스의 한계와 고민 테스트 코드 작성 소감 테스트 코드의 필요성 안정성 확보
ming123.tistory.com
Cypress의 단점 중 하나인 속도가 느리다는 피드백을 받았습니다.
설명을 중복해서 써도 테스트 시나리오를 직관적으로 확인하기 어렵다는 피드백을 받았습니다.
1. 천천히.
느린 해결책으로
beforeEach 대신 BeforeEach를 사용했습니다.
각 테스트 케이스가 실행될 때 로그인 관련 API와 cy.visit을 beforeEach에 적용하여 기존 로직에서
논리가 실행 중이어서 늦었습니다.
변경 전 코드
describe('첫 번째 테스트', () => {
beforeEach(() => {
cy.login(Cypress.env('email'), Cypress.env('password'));
navigateCy.partyQuestionStepOnePage();
});
it('(센터) SelectBox UI 확인', () => {
selectCenter();
});
});

내가 바꾼 코드
describe('첫 번째 페이지', () => {
before(() => {
cy.login(Cypress.env('email'), Cypress.env('password'));
navigateCy.partyQuestionStepOnePage();
});
describe('센터 SelectBox', () => {
it('(죽전 센터) 선택되어야 한다', () => {
selectCenter();
});
});
});

테스트 시간이 절반으로 줄어든 것을 볼 수 있습니다.
설명의 테스트 사례가 차례로 실행되는 경우 beforeEach는 항상 beforeEach 함수에 작성된 내용을 실행합니다.
즉, 초기화가 제대로 작동합니다.
다만, 비포의 경우 초기화 작업은 모든 테스트 케이스가 아니라 한 번만 하기 때문에 주의가 필요하다.
textField 또는 무언가에서 무료 ..
2. 테스트 시나리오를 직관적으로 확인하기 어렵다.
TextField의 Validate 검사와 Scenario 테스트를 위한 Formik, Cypress의 3가지 주요 UI를 해결하고 싶었습니다.
UI와 Formik은 단위 테스트와 유사하지만 jest 및 cypress와 같은 두 단위 테스트를 모두 작성하려면 관리가 필요합니다.
너무 많다고 생각해서 모두 편백나무로 써보았습니다.

그래서 UI를 확인하고, 도움말 텍스트를 확인하고, 버튼이 활성화되어 있는지 확인하고 시나리오 테스트를 작성했습니다.
이 부분은 다른 사람들이 직관적으로 확증하지 못할 수도 있다는 생각이 들었습니다.
다른 사람들이 시나리오 기반 테스트를 더 잘 볼 수 있도록 BDD를 참조했습니다.
BDD는 시나리오를 기반으로 테스트 사례를 작성하며 기능 단위 테스트를 권장하지 않습니다.
BDD와 관련하여 if ~이어야 하며 이에 따라 변경되었습니다.

조금 더 쉽게 볼 수 있는(?)
사실 프론트엔드 테스트 코드 작성이 어려운 이유 중 하나는 입력과 출력의 경계가 명확하지 않기 때문입니다.
백엔드의 경우 메서드를 테스트할 때 입력과 출력이 명확합니다.
그러나 프런트엔드는 TextField에 있습니다.
TextField UI 결과를 테스트의 출력으로 생각할 수 있습니다.
검증 테스트를 출력으로 생각할 수 있습니다.
다양한 시나리오에 따른 올바른 상황이나 API 응답이 테스트의 출력이라고 생각할 수 있습니다.
이러한 이유로 Storybook, Jest 및 Cypress와 같은 많은 테스트 라이브러리 및 도구가 있는 것 같습니다.
하지만 E2E는 한정된 인원(1인)이 테스트 코드를 쉽게 관리하면서 제품의 안정성을 보장하는 테스트라고 생각합니다.
시간이 날 때마다 글을 쓰려고 합니다.

