반복되는 설정값들 (viewport, baseUrl) 을 cypress.config.ts에 넣어두었습니다.
viewport의 경우 테스트 파일에서 작성시 기존 설정된 viewport값이 덮어씌워지므로 기존 코드를 변경할 필요는 없습니다.
baseUrl의 경우 테스트 파일에서 visit() 시 덮어씌워지지 않고 추가되므로 앞으로 테스트 작성함에 있어 주의가 필요합니다.
(예시 : cy.visit("/application");의 경우 기존 cy.visit(http://localhost:3000/application) 과 동일합니다)
유저 시나리오
- 초기 상태(아무 내용도 작성하지 않았을 경우)에서
- 다음 버튼을 누르면 “필수 질문을 작성해주세요.” 알림창이 뜬다.
- 질문 제목 네비게이션의 이후 질문을 누르면 “필수 질문을 작성해주세요.” 알림창이 뜬다.
- 이전 버튼 클릭시 이전 질문 페이지로 이동한다.
- 질문 제목 네비게이션의 이전 질문을 누르면 이전 질문 페이지로 이동한다.
- 유저가 답변 입력시
- 입력한 글자수를 볼 수 있다.
- 1000자 이하로 입력하였을 때, 다음 버튼을 누르면 다음 화면으로 이동한다.
- 유저가 답변 입력시 1000자 이하로 입력하였을 때, 질문 제목 네비게이션의 다음 질문을 누르면 다음 화면으로 이동한다.
- 1000자 이상 입력할 수 없다.
- 입력한 내용이 로컬스토리지에 올바르게 저장된다.
테스트 결과
![image](https://github.com/user-attachments/assets/b8431340-fb58-44ed-8efd-bc4e51a8607a)
고민 거리 공유
이번에 지원 동기 페이지 테스트를 하면서 해당 페이지까지 가기 위한 코드를 beforeEach에 작성해야 하는데, 지원 페이지의 뒷쪽의 페이지를 테스트 하게 될 때 그만큼 보일러플레이팅이 커지게 되고, (모든 테스트 케이스마다 해당 코드를 실행하기 때문에 ) 테스트 결과를 보는 시간도 그만큼 길어지게 된다는 문제를 인식했습니다.
개인적으로 테스트는 빨라야 한다고 생각합니다. 테스트 결과를 기다리는데에도 불필요한 비용이 발생하고, 이는 테스트를 통해서 얻고자 하는 여러 이점을 어느정도 무색하게 만들게 된다고 생각합니다. 지원 동기 페이지까지는 그래도 괜찮지만, 가장 마지막 페이지인 면접 시간 입력 페이지를 테스트 하게 된다면, 13개의 페이지를 이동햐아만 테스트를 진행할 수 있고 이를 모든 테스트케이스마다 반복하게 된다면.. 빌드 시간보다 길어질 수도 있지 않을까 생각이 듭니다
여기서 앞으로 페이지가 더 추가되게 된다면 더더욱 문제가 될 수 있을 것 같은데, 여러분들은 어떻게 생각하시는지 궁금합니다. 사실 문제라고 생각을 하지만, 이를 어떻게 해결해야할지에 대해서도 마땅한 해결책이 떠오르지 않네요.
리뷰어에게...
기존에 작성한 유저 시나리오를 바탕으로 지원 동기 페이지의 유저 시나리오를 작성하게 되었습니다. 이에 잘못된 시나리오가 있는지, 혹은 추가해야하는 시나리오가 있는지 확인 부탁드립니다!
주요 변경사항
지원 동기 페이지 e2e 테스트를 작성했습니다.
cy.visit("/application");
의 경우 기존cy.visit(http://localhost:3000/application)
과 동일합니다)유저 시나리오
- 초기 상태(아무 내용도 작성하지 않았을 경우)에서 - 다음 버튼을 누르면 “필수 질문을 작성해주세요.” 알림창이 뜬다. - 질문 제목 네비게이션의 이후 질문을 누르면 “필수 질문을 작성해주세요.” 알림창이 뜬다. - 이전 버튼 클릭시 이전 질문 페이지로 이동한다. - 질문 제목 네비게이션의 이전 질문을 누르면 이전 질문 페이지로 이동한다. - 유저가 답변 입력시 - 입력한 글자수를 볼 수 있다. - 1000자 이하로 입력하였을 때, 다음 버튼을 누르면 다음 화면으로 이동한다. - 유저가 답변 입력시 1000자 이하로 입력하였을 때, 질문 제목 네비게이션의 다음 질문을 누르면 다음 화면으로 이동한다. - 1000자 이상 입력할 수 없다. - 입력한 내용이 로컬스토리지에 올바르게 저장된다.테스트 결과
![image](https://github.com/user-attachments/assets/b8431340-fb58-44ed-8efd-bc4e51a8607a)고민 거리 공유
이번에 지원 동기 페이지 테스트를 하면서 해당 페이지까지 가기 위한 코드를 beforeEach에 작성해야 하는데, 지원 페이지의 뒷쪽의 페이지를 테스트 하게 될 때 그만큼 보일러플레이팅이 커지게 되고, (모든 테스트 케이스마다 해당 코드를 실행하기 때문에 ) 테스트 결과를 보는 시간도 그만큼 길어지게 된다는 문제를 인식했습니다.
개인적으로 테스트는 빨라야 한다고 생각합니다. 테스트 결과를 기다리는데에도 불필요한 비용이 발생하고, 이는 테스트를 통해서 얻고자 하는 여러 이점을 어느정도 무색하게 만들게 된다고 생각합니다. 지원 동기 페이지까지는 그래도 괜찮지만, 가장 마지막 페이지인
면접 시간 입력 페이지
를 테스트 하게 된다면, 13개의 페이지를 이동햐아만 테스트를 진행할 수 있고 이를 모든 테스트케이스마다 반복하게 된다면.. 빌드 시간보다 길어질 수도 있지 않을까 생각이 듭니다여기서 앞으로 페이지가 더 추가되게 된다면 더더욱 문제가 될 수 있을 것 같은데, 여러분들은 어떻게 생각하시는지 궁금합니다. 사실 문제라고 생각을 하지만, 이를 어떻게 해결해야할지에 대해서도 마땅한 해결책이 떠오르지 않네요.
리뷰어에게...
관련 이슈
closes #168